Hi, On Tue, Jul 6, 2010 at 6:03 AM, Balbir Singh <[email protected]> wrote: > * 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.
If backward compatibility is your only worry, then please check out the patches I have put up at http://libcg.git.sourceforge.net/git/gitweb.cgi?p=libcg/libcgroup-context.git;a=summary While it is a bit dated, I have not received any feedback/reviews from you yet. I have received some from Lennart (privately) and have modified a few of the patches. I will push them out in sometime soon (once i get a bit more time and testing done). Could you please review and try them out as well? (The patches up there have passed testing) > 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. > The only issue I see is that we are expecting users to use the library and interfaces in a certain way while it will be used in many other ways as well. We really cannot take responsibility for all these scenarios working, and need to pass on some of the responsibility to other programmers. Dhaval ------------------------------------------------------------------------------ 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
