Re: [Haskell-cafe] fcntl locks, executeFile and threaded runtime

Hi Donn, Thanks for your response. Here is more info, first what I'm trying to accomplish. The program I'm writing is a kind of supervisor (like daemontools), something to daemonize a process then report the state on zookeeper which is why I need the threaded runtime. That said, I'm aware of the limitations. But for this particular case I believe it is going to work. I was using the posix locks only to test whether or not the program I'm supervising is still alive, as they have the nice feature of returning the pid that actually holds the lock. Before writing to haskell-cafe@ I've been "stracing" this program trying to make some sense of it, with no luck. I'm could attach the results, but there is nothing there that could explain this behavior. Well, at least I could not figure it out. The reason that makes me believe that executeFile is the culpirt is that without that line it works. If you take that out and use 'threadDelay' for instance, the problem is gone. Ah, and for the mean time I'm using flock. This has no problems, which makes sense as the locks is per file handle not per process as the posix ones. ~dsouza At Fri, 25 Oct 2013 08:52:38 -0700 (PDT), Donn Cave wrote:

diego souza ,

...

I'm having problems with executeFile as it seems to clear the advisory locks using the threaded runtime.

I'm stumped, and unfortunately can't duplicate it here (no surprise as I have a different platform and GHC version.) But in case it helps ... your fcntl(2) file lock will be lost if your process closes any fd open on that file. So if the threaded runtime for some reason were to dup random fds and then close them, around a fork, that would do it. You might be able to pick that up in an strace (or whatever your platform utility for system call tracing.) But I don't see how executeFile could make any difference, in that scenario.

Donn

...

Consider the following snippet (a simplification of what I'm doing):

import System.IO import Control.Monad import System.Posix.IO import Control.Concurrent import System.Posix.Files import System.Posix.Process

main = do let lock = (WriteLock, AbsoluteSeek, 0, 0) fd <- openFd "/tmp/foobar" ReadWrite (Just stdFileMode) defaultFileFlags {trunc=True} pid <- forkProcess $ do setLock fd lock >> putStrLn "child: ok" executeFile "/usr/bin/sleep" False ["5"] Nothing threadDelay $ 1 * 1000 * 1000 setLock fd lock >> putStrLn "parent: fail!" void $ getProcessStatus True False pid

Then I consistentlty get these results:

$ ghc -threaded --make test.hs; ./test child: ok parent: fail!

$ ghc -rtsopts --make test.hs; ./test child: ok test: setLock: resource exhausted (Resource temporarily unavailable)

Any pointers? At first I though it might be an issue with the unix package but that doesn't seem to be the case.

$ ghc-pkg list | grep unix unix-2.6.0.1

$ ./test +RTS --info [("GHC RTS", "YES") ,("GHC version", "7.6.3") ,("RTS way", "rts_thr") ,("Build platform", "x86_64-unknown-linux") ,("Build architecture", "x86_64") ,("Build OS", "linux") ,("Build vendor", "unknown") ,("Host platform", "x86_64-unknown-linux") ,("Host architecture", "x86_64") ,("Host OS", "linux") ,("Host vendor", "unknown") ,("Target platform", "x86_64-unknown-linux") ,("Target architecture", "x86_64") ,("Target OS", "linux") ,("Target vendor", "unknown") ,("Word size", "64") ,("Compiler unregisterised", "NO") ,("Tables next to code", "YES") ]

Thanks! ~dsouza _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe