X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 22 Jul 2009 17:42:13 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: flock still buggy
Message-ID: <20090722154213.GL27613@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20090721T231647-613 AT post DOT gmane DOT org> <20090722100804 DOT GF27613 AT calimero DOT vinschen DOT de> <loom DOT 20090722T143408-726 AT post DOT gmane DOT org> <20090722150048 DOT GK27613 AT calimero DOT vinschen DOT de> <loom DOT 20090722T151319-66 AT post DOT gmane DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <loom.20090722T151319-66@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 Jul 22 15:27, Eric Blake wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 
> > > $ ./foo 4& sleep 2; ./foo 0
> > > 
> > > Oops - process 14060 got the lock before 12692 and 21704 exited.
> > 
> > This looks different with my patch:
> > 
> 
> Yep, so far, it looks like your patch follows the semantics I expect for every 
> one of my tests (the lock remains until explicitly unlocked, or until all 
> handles are closed, whether by explicit close, process exit, or close-on-
> exec).  And the original autoconf question which raised this issue in the first 
> place now passes.
> 
> I'm not sure whether there are lurking bugs in fcntl/lockf locking, but I think 
> we've finally nailed the last of the flock bugs.

Thanks, but no.  There's at least this one problem left which I simply
don't know how to fix.  The situation is thus:

  fd = open()
  fork ()
  --> child
      flock(fd, LOCK_SH);
      exit ();
        
The problem is that the lock disappears when the child exits, even
though the parent has still an open descriptor to the file.  This
problem disallows usage of the flock(1) utility like this:

  (
    flock -s 200
    # ... commands executed under lock ...
  ) 200>/var/lock/mylockfile

I wish I knew how to implement this...

> Nothing.  I guess I wasn't thinking straight on this case - a fork is
> not the same as exec, and I validated that even without your patch,
> flock(LOCK_UN) fails on closed fd, and close-on-exec does close the fd
> when I actually get to the exec.
> 
> By the way, your posted patch missed out on fhandler.cc; I assume this
> is what you meant:
> [...]

Exactly.  Thank you.  I'll apply the patch in a minute.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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