quoth Diego Souza, ...
I ruled out executeFile as creating the lock prior forking makes the problem vanish.
Well, yes, but you'd expect this if there's a problem with executeFile, wouldn't you? Because here both locks are attempted prior to executeFile, so it's kind of out of the picture. It might be interesting to use a `sleeplock' as below that accepts a FD parameter and attempts to lock it, and exec that from your Haskell main program. Then you can verify (I think) that if you use that in your initial configuration (where the parent locks second), it will always work when the exec'd program does the lock, but maybe fail when it's done prior to the exec (same program with no FD parameter.)
Posix locks are hard to work with. Flock is much better, which is what I'm using now
For sure, I'll go along with that. The operation of posix file locks should be down to the kernel/filesystem/etc., though, so it seems to me, if it's GHC's fault, the runtime must be doing something different to this fd at the syscall level. That's a fairly narrow set of possibilities. If we rule that out, and it really is something about thread scheduling etc., then it would have to be a Linux bug, wouldn't it? Donn ------------ import System.IO import System.Posix.IO import System.Posix.Files import System.Environment (getArgs) import System.Posix.Unistd (sleep) possiblyLock [] = return () possiblyLock (a:_) = do setLock (read a) (WriteLock, AbsoluteSeek, 0, 0) putStrLn "exec lock OK" main = do args <- getArgs possiblyLock (tail args) sleep (read (head args)) putStrLn "child waking up!"