For me, this example kind is of ambiguous. I thought it seemed clear enough

from your earlier results, that executeFile played some role in the problem,

but in this example the two locking forks are parallel, and it's entirely

possible that both lock syscalls will complete before either executeFile has

finished or even begun, so ... unless I'm missing something (again!) I guess

I would say this calls for a lot more tests to verify that you have this

problem only with executeFile, and not with, say, a Haskell fork that does

the same thing (sleep and exit.)

By the way, I haven't been able to duplicate the problem with 6.12.3 on MacOS.

I ruled out executeFile as creating the lock prior forking makes the problem vanish. So I though it

must be something else, which led me to the second example. I don't think it is related with threadDelay,

actually I'm thinking it must something to do with the threaded runtime.

I guess what you are missing is that fcntl locks are atomic and per process, so that:

* forkIO or forkOS are no replacement for this (they don't create new processes, just threads);

* setLock before executeFile is fine (fcntl locks are atomic), as long as the process does not terminates, or, sleep must be running so that the lock continues;

I found no evidence that sleep is terminating early (but I'll double check), and I'm certain that the two locks took place. But I can make these tests better.

I don't know why you can't reproduce this on MacOS. I have tried it in another linux machine (same architecture, different kernel, libc) and got pretty much the same results.

At any rate, if you have a better way to reproduce or rule out the problem, let me know. But I'll keep digging on this.

Posix locks are hard to work with. Flock is much better, which is what I'm using now.

Thanks!

~dsouza