* Lennart Poettering <[email protected]> [2010-07-05 22:57:20]: > 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... >
ABBA is a good point, it imposes lock ordering across all locks we have, not something we desire. However, I've been wonder how glibc handles all of this and provides thread safe functions. You might wonder why I want to have the locking around, there are three points 1. Application level serialization is more coarse than library level 2. I am concerned about changing applications that rely on the library locking behaviour, most applications live within libcg source base, but still I'd like to not break outside applications. 3. Thread based fork() -> exec() is a special scenario and currently our locks are not strongly ordered, so we'll need to review/monitor addition of new locks. The cgroup_mount_table_lock and rl_lock have no strong dependency, the current solution posted should work, ideally. > 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". > Thanks, I read through the RATIONALE. It does talk about issues and possible solutions to those. Having said that, I would like discussion from a broader group so that we can close this ASAP. -- Three Cheers, Balbir ------------------------------------------------------------------------------ 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
