flanker (./3917) :
Bin les logiciels en question n'ont qu'à respecter la norme POSIX

Manque de chance, fork est spécifié par POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html (et d'ailleurs, la révision de 2001 rajoute la phrase "After fork(), both the parent and the child processes shall be capable of executing independently before either one terminates." qui interdit fork=vfork, qui était encore toléré en 1998).

Le problème, c'est la clause: "Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called." à laquelle Apple rajoute "All APIs, including global data symbols, in any framework or library should be assumed to be unsafe after a fork() unless explicitly documented to be safe or async-signal safe. If you need to use these frameworks in the child process, you must exec." En gros, seul ce pour quoi POSIX exige que ce soit async-signal-safe l'est, toutes les APIs que OS X propose en dehors POSIX ne sont pas async-signal-safe! C'est "génial" quand tu dois utiliser une de leurs APIs non-standard pour intégrer ton application correctement à leur "UNIX, mais pas tout à fait".

Ce qu'il y a bien avec toi, c'est que tu considères que le standard à respecter est ce qui est ni un standard officiel (ISO), ni un truc utilisé sur la majorité des machines, mais bien un truc qui utilisé sur 1% des machines...

Le problème ici est que leur interprétation du standard POSIX n'est pas raisonnable, ils n'implémentent que le strict minimum pour être certifiables UNIX, toutes les options prévues pour un système desktop ne marchent pas et l'interopérabilité entre les APIs POSIX et leurs APIs propriétaires est pourrie (comme dans le cas présent)!