Tout est relatif... Ca dépend de ce que tu appel récemment, mais perso, je ne pense pas que les linux < 2.4 soit encore tellement utilisé que ca, sauf cas très particulier.
On peut donc douter de sa portabilité.
Dans l'absolue ca n'est pas faux. Mais en pratique, et si tu te limite aux systèmes les plus courrant (Linux, *BSD, MacOSX, cygwin...), ca ne pose apparament aucun problème hormis le fait que certain systèmes définissent encore MAP_ANON à la place de MAP_ANONYMOUS.
Pour info, juste un example. MAP_ANONYMOUS est utilisé dans MPlayer pour allouer une zone mémoire en lui attribuant le droit PROT_EXEC afin de pouvoir executer du code qui est généré à l'execution. (sans ce PROT_EXEC, tu obtient un jolie segfault sur les CPU gérant la protection en exexecution, tel le NX bit des AMD64)
En pratique il s'avère que MPlayer ne se débrouille pas trop mal pour ce qui est de la portabilité.
Donc a moins que ta cible ne soit des systèmes vraiment très exotiques, je ne pense pas que la portabilité soit un si gros problème.
En ce qui concerne Linux, tu as essayé pour voir si les autres threads faisaient un sigsegv ?
Non, je n'ai pas fait ce genre de test avec des threads.
Les threads et autre fork c'est sympa, mais quand on peut les éviter c'est encore mieux ;-)
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par aurelj . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
exact.
et est apparu récemment dans Linux.
Tout est relatif... Ca dépend de ce que tu appel récemment, mais perso, je ne pense pas que les linux < 2.4 soit encore tellement utilisé que ca, sauf cas très particulier.
On peut donc douter de sa portabilité.
Dans l'absolue ca n'est pas faux. Mais en pratique, et si tu te limite aux systèmes les plus courrant (Linux, *BSD, MacOSX, cygwin...), ca ne pose apparament aucun problème hormis le fait que certain systèmes définissent encore MAP_ANON à la place de MAP_ANONYMOUS.
Pour info, juste un example. MAP_ANONYMOUS est utilisé dans MPlayer pour allouer une zone mémoire en lui attribuant le droit PROT_EXEC afin de pouvoir executer du code qui est généré à l'execution. (sans ce PROT_EXEC, tu obtient un jolie segfault sur les CPU gérant la protection en exexecution, tel le NX bit des AMD64)
En pratique il s'avère que MPlayer ne se débrouille pas trop mal pour ce qui est de la portabilité.
Donc a moins que ta cible ne soit des systèmes vraiment très exotiques, je ne pense pas que la portabilité soit un si gros problème.
En ce qui concerne Linux, tu as essayé pour voir si les autres threads faisaient un sigsegv ?
Non, je n'ai pas fait ce genre de test avec des threads.
Les threads et autre fork c'est sympa, mais quand on peut les éviter c'est encore mieux ;-)