"Et si un pointeur mal programmé essaye de modifier ces données, sigsegv".
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
??? sigsegv est généré automatiquement par le hardware sans ralentir quoique ce soit. Et uniquement s'il y a un gros bug qu'il vaut mieux détecter de suite.
Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon.
Justement un shm est la propre mémoire d'un processus. C'est bien ça le principe. Un système qui teste les droits du shm à chaque accès au lieu de le faire une fois pour toutes lors de l'attachement, n'est certainement pas un système POSIX.
Ceci étant je suis un très grand fan de SHM,
SHaiMe, c'est être fan :)
[^] # Re: vs POSIX shared memory
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
??? sigsegv est généré automatiquement par le hardware sans ralentir quoique ce soit. Et uniquement s'il y a un gros bug qu'il vaut mieux détecter de suite.
Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon.
Justement un shm est la propre mémoire d'un processus. C'est bien ça le principe. Un système qui teste les droits du shm à chaque accès au lieu de le faire une fois pour toutes lors de l'attachement, n'est certainement pas un système POSIX.
Ceci étant je suis un très grand fan de SHM,
SHaiMe, c'est être fan :)