On Tue, 06.07.10 09:33, Balbir Singh ([email protected]) wrote: > 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
Neither do I see why that would be the case, nor do I see why that would be a problem. Are you afraid of performance issues? Well, if you remove the locks, and people can instantiate an independent context for each of their worker threads all locks would go away, and things would be even faster! That said, this stuff is in no way relevant for perfomance. Nobody uses this stuff in inner loops, so perfomance simply doesn't matter. > 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. You are creating more problems with this than you are solving. > 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. I'd just remove them. Less problems to think about. Faster. Easier. And just 200% more awesome. Userspace programmers who use low-level APIs like this one tend to know the locking problems quite well. There's not need in trying to outsmart them and provide locking in the library, assuming that the users weren't as good at this as you are. Lennart -- 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
