A mon avis, l'utilisation de mprotect() aura effet sur tous les threads
du processus.
Les threads se partagent exactement le même espace d'adressage
(logique, c'est le principe même). Concrètement, au niveau de la MMU
ça veut dire mêmes tables de pages ("mêmes" dans le sens
"partagées", pas recopiées entre threads).
Vu que les tables de pages sont les mêmes, un appel à mprotect()
qui modifie justement ces tables de pages impliquera que l'action
impactera tous les threads.
Pour info, sur les CPU i386, un changement de tâche se fait à l'aide
d'un changement de TSS (Task State Segment). Dans ce TSS, on
trouve le registre CR3 qui indique l'adresse du catalogue de pages
(lui même pointant vers les tables de pages). Pour toutes les threads
d'un même processus, le registre CR3 est le même.
[^] # Re: vs POSIX shared memory, read-only
Posté par galactikboulay . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
du processus.
Les threads se partagent exactement le même espace d'adressage
(logique, c'est le principe même). Concrètement, au niveau de la MMU
ça veut dire mêmes tables de pages ("mêmes" dans le sens
"partagées", pas recopiées entre threads).
Vu que les tables de pages sont les mêmes, un appel à mprotect()
qui modifie justement ces tables de pages impliquera que l'action
impactera tous les threads.
Pour info, sur les CPU i386, un changement de tâche se fait à l'aide
d'un changement de TSS (Task State Segment). Dans ce TSS, on
trouve le registre CR3 qui indique l'adresse du catalogue de pages
(lui même pointant vers les tables de pages). Pour toutes les threads
d'un même processus, le registre CR3 est le même.