J'ai envisagé d'utiliser puis-je supposer mmap pour la lecture de fichiers et je vous demandais comment portable c'est-à-dire.
Je développe une plate-forme Linux, mais je voudrais que mon programme fonctionne sur Mac OS X et Windows.
mmap fonctionne sur ces plates-formes?
4 Réponses :
Le principe d'un fichier mappé de mémoire est assez portable, mais vous n'avez pas de MMAP () sur Windows (mais des choses comme MapViewOffile () existent). Vous pouvez jeter un coup d'œil au code Python Mme Modules C pour voir comment ils le font pour différentes plates-formes.
the mmap () La fonction est un appel POSIX. Cela fonctionne bien sur MacOS X (et Linux, HP-UX, AIX, et Solaris).
La zone problématique sera Windows. Je ne suis pas sûr de savoir s'il existe un Si vous essayez de cartographier des fichiers volumineux sur un système 32 bits, vous trouverez peut-être qu'il n'y a pas assez d'espace contigu pour allouer tout le fichier en mémoire, de sorte que la cartographie de la mémoire échouera. Ne supposez pas que cela fonctionnera; décider de votre stratégie de secours si elle échoue. _mmap () appelle dans le sous-système "Compatibilité" de POSIX. Il est probable qu'il y ait là-bas - mais aura le nom avec le soulignement de premier plan, car Microsoft a une vision alternative sur les espaces de noms et les considérons mmap () pour s'immiscer dans l'espace de nom d'utilisateur, même si vous demandez à POSIX Fonctionnalité. Vous pouvez trouver une définition d'une alternative interface Windows MapViewOffile () et discussion sur la performance dans une autre question à une autre question ( mmap () vs blocs de lecture ).
Utiliser le MMAP pour la lecture de fichiers n'est pas portable si vous comptez sur la cartographie des gros bits de fichiers volumineux dans votre espace d'adressage - les systèmes 32 bits peuvent facilement ne pas avoir un seul grand espace utilisable - disons 1G - d'espace d'adressage disponible ainsi échouerait assez souvent pour une cartographie 1G.
Je considère que la mémoire mappe IO sur UNIXS Comme non utilisable pour les applications interactives, Comme cela pourrait entraîner un SIGSEGV / SIGBUS (dans le cas du fichier a été tronqué dans l'entre eux par un autre processus). Ignorer ces "solutions" malade que SETJMP / LONDJMP Il n'y a que rien ne peut faire autre chose que de mettre fin au processus après avoir obtenu SIGSEGV / SIGBUS. La nouvelle fonctionnalité G ++ pour convertir de tels signaux en exceptions semble être destiné principalement aux pommes OS, Depuis que la description indique que l'on a besoin d'un support d'exécution pour cette fonctionnalité G ++ Et il n'y a aucune information à trouver sur cette fonctionnalité g ++ n'importe où. Nous devons probablement attendre quelques années, jusqu'à ce que la manipulation d'exception structurée comme on puisse être trouvée sur Windows depuis plus de 20 ans en fait son chemin dans UNIXS.
Bien que vous ne répondiez pas directement à la question, j'ai trouvé cela vraiment utile, merci.
mémoire mappée IO ne pas être utilisable pour des applications non triviales sur UNIXS affecte la transférabilité de la mémoire mappée io
Pourquoi feriez-vous l'autre processus tronquer votre dossier si vous connaissez l'application s'écraserait? (En tant que protection contre l'incompétence de l'utilisateur, il y a le mécanisme de verrouillage basé sur FCNTL () assez standard.)
Bien que ma réponse ne traite pas de l'aspect portatif du MMAP, Boost propose des alternatives dans Boost.InterProcess et Boost.Istreams qui semble fonctionner sur Linux comme Windows.