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

[diego souza]

> 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.

Right, it does make a lot sense. :-)

> 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.)

Locking from the child *always* works, so I'll hope you guys trust me
and I'm not including any code.

I've done two versions of the same program, a simplified one. One in C
and another in haskell. They just 'forkProcess', 'setLock' and
'execFile'. I have tested the haskell version in three different
linuxs systems and one macosx box:

  * ubuntu (kernel 3.11/ghc 7.6.3)
  * archlinux (kernel 3.11/ghc 7.6.3);
  * debian (kernel 3.9/ghc 7.4.1);
  * macos mavericks/ghc 7.6.3;

I can't reproduce the bug on macos. It never fails.

The c version (attached file c_fcntl.c) using the test_fcntl.sh (also
attached), as expected, never fails:

$ gcc -o c_fcntl c_fcntl.c
$ sh test_fcntl.sh ./c_fcntl 2>/dev/null
./c_fcntl: ok: 1; fail: 0
./c_fcntl: ok: 2; fail: 0
./c_fcntl: ok: 3; fail: 0
./c_fcntl: ok: 4; fail: 0
./c_fcntl: ok: 5; fail: 0
./c_fcntl: ok: 6; fail: 0
./c_fcntl: ok: 7; fail: 0
./c_fcntl: ok: 8; fail: 0
./c_fcntl: ok: 9; fail: 0
./c_fcntl: ok: 10; fail: 0
./c_fcntl: ok: 11; fail: 0

Now the haskell version (attached file hs_fcntl.hs), I'm including
only one output, but it is pretty much the same on all machines:

$ ghc -threaded hs_fcntl.hs
$ sh test_fcntl.sh ./hs_fcntl 2>/dev/null
./hs_fcntl: ok: 0; fail: 1
./hs_fcntl: ok: 0; fail: 2
./hs_fcntl: ok: 0; fail: 3
./hs_fcntl: ok: 0; fail: 4
./hs_fcntl: ok: 0; fail: 5
./hs_fcntl: ok: 0; fail: 6
./hs_fcntl: ok: 0; fail: 7
./hs_fcntl: ok: 0; fail: 8
./hs_fcntl: ok: 0; fail: 9
./hs_fcntl: ok: 0; fail: 10
./hs_fcntl: ok: 0; fail: 11

Now this outcome seem pretty easy to reproduce on linux systems, I
guess. If you guys could try it on some linux machine I would
appreciate [or let me know if you don't think this is a valid test].

Regarding the previous program, specially the on that did two
'forkProcess', I could see something from the strace output, but I
can't relate to anything documented or that I'm aware of.

On my machine, it seems that if the 'execve' happens before the second
'fcntl' the lock fails (as must be happening in the hs_fcntl.hs). I
have tried a number of times and it really seems to be the case. It
only works when the two 'fcntl' happens before any 'execve'. But I
can't say for sure this is the case in other systems.

The only thing that happens during an 'execve' that comes to mind is
that it kills all threads but the current one. And I do see this
happening on the trace output.

But I guess this should make no difference (unless it seems it does).

Well, right now I'm pretty much without pointers. :-)

Thanks!
~dsouza

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_fcntl.hs
Type: application/octet-stream
Size: 693 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131029/931c91d5/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: c_fcntl.c
Type: application/octet-stream
Size: 830 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131029/931c91d5/attachment-0001.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_fcntl.sh
Type: application/octet-stream
Size: 284 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131029/931c91d5/attachment-0002.obj>
-------------- next part --------------