X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Mon, 20 Apr 2009 20:44:11 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] flock change breaks autotools 'make -j2'
Message-ID: <20090420184411.GE8722@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20090416T201917-225 AT post DOT gmane DOT org> <20090417100148 DOT GD5200 AT calimero DOT vinschen DOT de> <49E87CFA DOT 9070709 AT byu DOT net> <20090417133103 DOT GG8722 AT calimero DOT vinschen DOT de> <loom DOT 20090420T150238-584 AT post DOT gmane DOT org> <20090420153442 DOT GB8722 AT calimero DOT vinschen DOT de> <loom DOT 20090420T170835-58 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20090420T170835-58@post.gmane.org>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/