http://bugzilla.novell.com/show_bug.cgi?id=1018908
http://bugzilla.novell.com/show_bug.cgi?id=1018908#c6
--- Comment #6 from Michael Matz
OK, thanks for the explanation. So the problem now is that in the POSIX manual page for fork() it says all file locks should not be inherited, but then goes on to say that the states of objects such as mutexes may be copied to the new process so you should call exec (as you say).
I am wondering what locks it could be referring to here?
I'm wondering the same. It talks about "file locks" but doesn't say which particular file locks it means. It could also mean the fcntl(2) locks which are more explicitly mentioned in the linux manpages (and the POSIX one for fcntl also has coverage) as not being inherited. It could also mean any of the other dozen ways to implement file locks. So I fear that's not very helpful as description in this case. Probably that would really need to be clarified with POSIX but I wouldn't hold my breath.
Clearly the original test author thought that 'file locks' referred to the POSIX file locks implemented by libc for thread synchronisation.
Yes. My inclination would be that "file locks" in the POSIX fork manpage really mean the fcntl record locks. OTOH it could _also_ be that the glibc and linux manpage authors misunderstood the intent of the POSIX spec and that they were the ones that thought "file locks" were the fcntl ones, where POSIX indeed might have meant the flockfile stdio ones. :-/ In practice I think the it's a bit mood. Reality since a long time is such that fork doesn't inherit fcntl record locks, but somewhat (depending on circumstances) does inherit flockfile locks, so any programs in existence are probably fine with this behaviour. So even if the testcase does test the original intention of POSIX (which would remain to be seen) it would seem to not matter much. Possibly libc could unlock all FILE stdio lock with its atfork handler, I don't know if that would break anything. -- You are receiving this mail because: You are on the CC list for the bug.