On Mon, 05.07.10 23:46, Balbir Singh ([email protected]) wrote: > Hi,
Heya, > > I coded up the first bits for pthread_atfork() handling. I have no > real application to validate it against, but while I work on a test > case I wanted to get early feedback to see if we should look at this > direction. Uh. I think this is generally the wrong approach: you should get rid of the locks not add more locking code everywhere. The whole idea of pthread_atfork() is just wrong, due to ABBA and stuff. Since ordering cannot be controlled it's a call for deadlocks, not a path to peace and prosperity... Really, I believe this goes 180° in the wrong direction. pthread_atfork() is a problem in itself, not a solution. And POSIX actually acknowledges that in the spec: http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.html under "RATIONALE". ennart -- Lennart Poettering - Red Hat, Inc. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
