Mémoire partagée

Qt XML fournit deux techniques pour partager la mémoire avec d'autres processus dans le même système : QSharedMemory et les fichiers mappés en mémoire en utilisant QFile. La mémoire partagée avec d'autres processus est souvent appelée "segment", et bien qu'elle ait pu être implémentée sous forme de segments spécifiques sur des processeurs avec des modèles de mémoire segmentée dans le passé, ce n'est pas le cas dans les systèmes d'exploitation modernes. Les segments de mémoire partagée sont simplement des régions de mémoire dont le système d'exploitation s'assure qu'elles sont disponibles pour tous les processus participants.

Le partage de la mémoire à l'aide de QSharedMemory

QSharedMemory fournit une API simple pour créer un segment de mémoire partagée d'une taille donnée ou pour s'attacher à un segment créé par un autre processus. En outre, il fournit une paire de méthodes pour lock et unlock l'ensemble du segment, en utilisant un QSystemSemaphore interne.

Les segments de mémoire partagée et les sémaphores du système sont globalement identifiés dans le système par une "clé" qui, dans Qt XML, est représentée par la classe QNativeIpcKey. En outre, en fonction du système d'exploitation, Qt peut prendre en charge plusieurs backends différents pour le partage de la mémoire ; voir la documentation sur les clés IPC natives pour plus d'informations et les limitations.

QSharedMemory est conçu pour partager la mémoire uniquement au sein du même niveau de privilège (c'est-à-dire pas avec d'autres processus non fiables, tels que ceux lancés par d'autres utilisateurs). Pour les backends qui le supportent, QSharedMemory créera des segments de telle sorte que seuls les processus ayant le même niveau de privilège puissent s'y attacher.

Partage de la mémoire via des fichiers mappés en mémoire

La plupart des fichiers peuvent être mis en mémoire à l'aide de QFile::map() et, si l'option MapPrivateOption n'est pas spécifiée, toute écriture sur le segment mis en mémoire sera observée par tous les autres processus qui ont mis en mémoire le même fichier. Les exceptions aux fichiers pouvant être mis en mémoire sont les fichiers distants trouvés dans les partages de réseau ou ceux situés dans certains systèmes de fichiers. Même si le système d'exploitation autorise le mappage de fichiers distants en mémoire, les opérations d'E/S sur le fichier seront probablement mises en cache et retardées, ce qui rendra impossible un véritable partage de la mémoire.

Cette solution présente l'avantage majeur d'être indépendante de toute API dorsale et d'être plus simple à interopérer avec des applications non Qt. Puisque QTemporaryFile est une classe QFile, les applications peuvent utiliser cette classe pour obtenir une sémantique de nettoyage et pour créer des segments de mémoire partagée uniques.

Pour verrouiller le segment de mémoire partagée, les applications devront déployer leurs propres mécanismes. Une solution consiste à utiliser QLockFile. Une autre solution, moins coûteuse, consiste à utiliser QAtomicInteger ou std::atomic dans un décalage prédéterminé dans le segment lui-même. Des primitives de verrouillage de plus haut niveau peuvent être disponibles sur certains systèmes d'exploitation ; par exemple, sous Linux, les applications peuvent définir l'indicateur "pshared" dans l'attribut mutex transmis à pthread_mutex_create() pour indiquer que le mutex réside dans un segment de mémoire partagée.

Il faut savoir que le système d'exploitation tentera probablement d'enregistrer en mémoire permanente toutes les écritures effectuées dans la mémoire partagée. Cela peut être souhaité ou constituer une pénalité en termes de performances si le fichier lui-même est censé être temporaire. Dans ce cas, les applications doivent trouver un système de fichiers adossé à la RAM, tel que tmpfs sous Linux (voir QStorageInfo::fileSystemType()), ou passer un drapeau à la fonction native d'ouverture de fichier pour informer le système d'exploitation d'éviter d'engager le contenu dans le stockage.

Il est possible d'utiliser la mémoire partagée adossée à un fichier pour communiquer avec des processus non fiables, auquel cas l'application doit faire preuve d'une grande prudence. Les fichiers peuvent être tronqués et faire planter les applications qui accèdent à la mémoire au-delà de la taille du fichier.

Conseils Linux sur les fichiers mappés en mémoire

Sur les systèmes Linux modernes, bien que le répertoire /tmp soit souvent un point de montage tmpfs, ce n'est pas une obligation. Cependant, le répertoire /dev/shm doit être un tmpfs et existe dans le but précis de partager la mémoire. Notez qu'il est lisible et inscriptible par le monde entier (comme /tmp et /var/tmp), et que les applications doivent donc faire attention au contenu qui y est révélé. Une autre solution consiste à utiliser le répertoire d'exécution XDG (voir QStandardPaths::writableLocation() et QStandardPaths::RuntimeLocation), qui, sur les systèmes Linux utilisant systemd, est un répertoire propre à l'utilisateur tmpfs.

Une solution encore plus sûre consiste à créer un "memfd" à l'aide de memfd_create(2) et à utiliser la communication interprocessus pour transmettre le descripteur de fichier, comme QDBusUnixFileDescriptor ou en laissant le processus enfant d'un QProcess en hériter. Les "memfds" peuvent également être scellés contre le rétrécissement, de sorte qu'ils peuvent être utilisés en toute sécurité lors de la communication avec des processus ayant un niveau de privilège différent.

Conseils de FreeBSD sur les fichiers en mémoire

FreeBSD dispose également de memfd_create(2) et peut transmettre des descripteurs de fichiers à d'autres processus en utilisant les mêmes techniques que Linux. Les systèmes de fichiers temporaires ne sont pas montés par défaut.

Conseils de Windows sur les fichiers en mémoire

Sous Windows, l'application peut demander au système d'exploitation d'éviter d'enregistrer le contenu du fichier sur un support permanent. Cette demande est effectuée en passant l'indicateur FILE_ATTRIBUTE_TEMPORARY dans le paramètre dwFlagsAndAttributes de la fonction Win32 CreateFile, l'indicateur _O_SHORT_LIVED à la fonction de bas niveau _open(), ou en incluant le modificateur "T" à la fonction d'exécution C fopen().

Il existe également un indicateur permettant d'informer le système d'exploitation de la nécessité de supprimer le fichier lorsque la dernière poignée est fermée (FILE_FLAG_DELETE_ON_CLOSE, _O_TEMPORARY, et le modificateur "D"), mais il convient de noter que tous les processus qui tentent d'ouvrir le fichier doivent s'accorder sur l'utilisation ou non de cet indicateur. Un désaccord entraînera probablement une violation de partage et l'impossibilité d'ouvrir le fichier.