This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [1.7] flock change breaks autotools 'make -j2'
On Apr 20 17:45, Eric Blake wrote:
> 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
Sorry, but I don't understand what you mean. The flock code neither
uses shared memory, nor is it restricted to a user session. Rather,
it uses mutexes and event objects in the global NT namespace for
synchronizing. Every file for which one of the lock functions is
called gets its own directory in the global NT namespace, based on
the inode number. When I implemented the advisory locking code I also
tested locking the same file from within different user sessions and
it worked (apart from the bugs we found testing 1.7 so far).
> - 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.
Cygwin's global shared memory is not restricted to a user session
anymore starting with 1.7, due to the way it's using the global NT
namespace.
> 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.
Again, I don't understand the actual problem you're referring to.
The process hierarchy shouldn't matter at all...
...uhm...
...unless you're talking about actual BSD flock(2) semantics and how
flock locks are bound to the file descriptor, rather than to the
process. I guess I start to understand your problem. Sure, the
flock lock is inherited to the child process but starting a Cygwin
child process via a debugger breaks inheriting the data attached to
the descriptor. Thus also the fact that this is a descriptor with
an active flock lock is forgotten in GDB's child process.
Yeah, nothing I can do about that. Attaching to the running process
is necessary to debug this.
> 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?
Since you're building your own Cygwin anyway, feel free to add that
code yourself. The actual wait occurs in flock.cc, function lf_setlock,
lines 941ff. Core of the unlocking code is the method
lockf_t::del_lock_obj flock.cc lines 583ff. Closing a descriptor (close,
close-on-exec) trigger a call to fhandler_base::del_my_locks, flock.cc
lines 346ff.
Apart from that, I tried to document the code in flock.cc excessivly
because this synchronization stuff is usually tricky enough to forget
even your own code after a while...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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/