Comment # 5 on bug 1018908 from Richard Palethorpe

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? Perhaps it means "if
the parent has locked a file through the kernel, then the child should _not_ be
able to access the file" or it could mean that during the fork the thread locks
are removed from the child's memory so that the child _can_ access the file. In
other words, depending on how you interpret the word 'inherit' and the phrase
'file locks' it could mean one of two complete opposites.

Incidentally the file lock succeeds if we call ftrylockfile in the child's main
thread so presumably the thread ID is the same between child and parent. The
test creates another thread in the child before trying to lock the file.
Previously the test passed when doing this.

Clearly the original test author thought that 'file locks' referred to the
POSIX file locks implemented by libc for thread synchronisation.