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

[Diego Souza]

> ​​
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131028/1bac28ec/attachment.html>