Re: [1.7] flock change breaks autotools 'make -j2'

[Eric Blake <ebb9 at byu dot net>]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> Because this testcase works fine.  I hope it's not trying to do this:
> 
>   parent opens file
>   fork
>     child calls flock()
>     exit
>   fork
>     second child relies on the lock.
> 
> because this is exactly the scenario which doesn't work with flock
> right now.  I have it on my TODO list, but so far I'm at a loss as
> to how to implement it.

As far as I can tell, the original case doesn't look like that.  From the 
strace I ran, flock was only called on the fd obtained several lines earlier by 
the same perl process, and I don't see any child processes trying to perform 
flock manipulations on the fd inherited from the parent.  But I'm still trying 
to figure out what is different between the 'make -j2' case and my simpler C 
program (which I wrote before I saw this mail, but which looked awfully similar 
to yours).

I did notice that flock only seems to protect processes spawned in the same 
cygwin process hierarchy - using strace to spawn my test program created a new 
hierarchy, and thus did not see the lock held by the old hierarchy.  That does 
not affect the original testcase, where all processes involved are in the same 
hierarchy.  And I guess it makes sense - since we aren't modifying the inodes 
of the actual file system, the cygwin notion of an inode (where BSD flock 
locking takes place) is necessarily limited to the shared memory among a cygwin 
process hierarchy, and we shouldn't have to worry about independent process 
hierarchies.  But it does mean that it is harder to debug the issue, because it 
is no longer a simple matter of using strace or gdb to run the test app, but 
instead requires process attachment to keep the test programs within the same 
process hierarchy.

Maybe we should teach strace to output when an flock release occurs due to 
closing the last handle to a file, to see if that sheds any more insight.  
Perhaps also an strace line just before a process blocks because it detects 
that some other process already holds a lock; if nothing else, so that we can 
see how long the flock call blocks?

-- 
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/