Comment utiliser mmap, pour allouer de la mémoire dans le tas?

Juste à la question posée, comment puis-je utiliser mmap(), pour allouer de la mémoire dans le tas? C'est ma seule option, car malloc() n'est pas une fonction réentrante.

Si votre malloc() n'est pas réentrant, ne serait-il pas plus simple d'écrire un wrapper avec une serrure au lieu de rouler votre propre ensemble de la mémoire système?
mmapped de la mémoire n'est ni de tas, ni pile, donc je n'ai aucune idée de ce que vous demandez ici.
Le verrouillage ne peut pas faire un non réentrant fonction réentrante. Il ne peut le faire non thread-safe fonctions de thread-safe. Réentrant est un beaucoup plus forts condition.
si il veut de fonctionner dans les gestionnaires de signaux, un verrou ne va pas être assez bon.

OriginalL'auteur domlao | 2011-01-24

  1. 22

    Pourquoi avez-vous besoin de réentrée? Le seul temps qu'il faut pour l'appel d'une fonction à partir d'un gestionnaire de signal; sinon, le fil de sécurité est tout aussi bon. Les deux malloc et mmap sont thread-safe. Ni est asynchrone-signal-sûr par POSIX. Dans la pratique, mmap probablement fonctionne très bien à partir d'un gestionnaire de signal, mais l'idée de l'allocation de mémoire à partir d'un gestionnaire de signal est une très mauvaise idée.

    Si vous souhaitez utiliser mmap pour allouer de la mémoire anonyme, vous pouvez utiliser (pas à 100% portable, mais certainement le meilleur):

    p = mmap(0, size, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);

    Le portable mais laide version:

    int fd = open("/dev/zero", O_RDWR);
p = mmap(0, size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);

    Noter que MAP_FAILED, pas NULL, est le code de l'échec.

    Il n'est pas conforme à la façon d'allouer de la mémoire, mais mmap sera "probablement" de travail. Il serait beaucoup mieux de corriger la conception qui fait qu'il est nécessaire d'allouer de la mémoire à partir d'un gestionnaire de signal. Normalement, un gestionnaire de signal doit soit ne rien faire, ou tout simplement régler une seule variable d'indicateur ou d'écrire un octet dans un tuyau.
    Par ailleurs, depuis que "ne rien faire" n'a probablement pas été clair, "ne rien faire" gestionnaire de signal est utile avec le SA_RESTART drapeau omis d'interrompre les syscalls. Réglage d'un gestionnaire de signal pour interrompre les appels et et à l'aide de pthread_kill pour envoyer le signal à un fil est un moyen de "rouler" le fil d'annulation, sans l'irrécupérable ressources les problèmes de fuite de pthread_cancel conduit à. Il peut également être utile avec un seul thread si vous définissez un timer/alarme pour générer le signal, pour définir les délais d'attente pour les appels.
    La plupart des version portable est probablement de ne pas ouvrir /dev/zero mais à utiliser shm_open au lieu de cela, en interne qui ne à propos de la même chose, mais ne nécessite pas votre système de fichiers avec des fichiers spéciaux.
    Est MAP_PRIVATE valide avec de la mémoire partagée obtenus via shm_open? Je suppose que oui, puisque je ne pouvais pas trouver n'importe où il est explicitement interdit, mais cela semble contre-intuitif.
    Simplement pour stocker la taille au début de la mmap-bloc alloué, et retourne un pointeur sur l'octet juste après l'endroit où la taille est stocké. Ensuite libérer le bloc est aussi facile que la sauvegarde de lire de la taille et de l'adoption de la nouvelle pointeur et la taille de munmap.

    OriginalL'auteur R..

  2. 9

    Faire un simple la dalle de l'allocateur

    Bien que l'allocation de mémoire dans un gestionnaire de signal1 ne semble pas comme quelque chose à éviter, il peut certainement être fait.

    Non, vous ne pouvez pas utiliser directement la fonction malloc(). Si vous voulez qu'il soit dans le tas avec mmap ne fonctionne pas, soit.

    Ma suggestion est que vous faites une la dalle de l'allocateur basé sur le malloc.

    Décider exactement ce que la taille de l'objet que vous voulez et préallouer certains nombre d'entre eux. Attribuer initialement avec malloc() et de les enregistrer pour une utilisation concomitante plus tard. Il y a intrinsèquement réentrant de la file d'attente-et-un-file d'attente de fonctions que vous pouvez utiliser pour obtenir et libérer ces blocs. Si seulement ils doivent être gérés à partir du gestionnaire de signal puis ce n'est même pas nécessaire.

    Problème résolu!

    1. Et si vous ne faites pas cela, alors il semble que vous ayez un système intégré ou pourrait simplement utiliser malloc().

    Merci beaucoup. C'est très intéressant de détails.

    OriginalL'auteur DigitalRoss