delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2014/02/10/05:49:01

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; q=dns; s=
default; b=hjhkUH6Bv06RfMtz8N06VrGgEUppOvGb1TyAokaRjSgqXMgWRyuFi
0xYRZ7+WTj3GtwktoxlQHjbA9c1DVEhmzNZ7BKmoPXslyNYsff+gvMdvALYZ4TT2
1LnFFwkO7EuuAmTfbRBgEgO3Ih9GvdisI9qnzTh4WQxFuHx4xptI4w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; s=default;
bh=Y92mTTnIj2AaiRtBaf2PmhDRJGA=; b=PnaCafxp1JBw7vrtaZyUuS57vtO8
vJ1nRu2/NuDYPgHAacidfYjMoUgRupZeBoJ+e1b46gj/zRJIU6IYbrEzHJjNzmCw
Q0JdC0ASxTxbZRmHvC5BBdQXoSOIHW6hH7i1OX9GE9Qfa7jTbZeidXwhHmNO5tAw
C734RkP5NiRF4BU=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Mon, 10 Feb 2014 11:48:40 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: spawnv() unlocks files in the calling program
Message-ID: <20140210104840.GA31131@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <040201cf25c4$54e9cd20$febd6760$@lbmsys.com> <20140209192859 DOT GG2821 AT calimero DOT vinschen DOT de> <041d01cf25d2$6a59e5b0$3f0db110$@lbmsys.com> <20140209203825 DOT GJ2821 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
In-Reply-To: <20140209203825.GJ2821@calimero.vinschen.de>
User-Agent: Mutt/1.5.21 (2010-09-15)

--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Feb  9 21:38, Corinna Vinschen wrote:
> On Feb  9 15:06, Steven Bardwell wrote:
> > > How do you test that?  You're calling fcntl(F_SETLKW) exactly once at
> > > the start of your test application, but never again later.  We're
> > > talking advisory file locking here, so, where's the next fcntl call
> > > waiting for the lock?
> > >=20
> > > I debugged your test app and the lock still exists after the spawn ca=
ll.
> > >=20
> > >=20
> > >=20
> > > Corinna
> >=20
> > To test this, I start this program to check for the lock:
>=20
> Ok, I can reproduce it, but it's too late to debug this today.
>=20
> I have to say, though, that fcntl advisory locking is POSIX
> functionality, while the spawn functions are not.  In fact these dreaded
> spawn entry points are rather old stuff, which hasn't been tested for a
> long time.  FWIW, advisory file locking has never been tested with them,
> and the fact that it doesn't work as expected doesn't exactly disturb me.

I found the reason.  On UNIX, an exec'ed process substitutes the calling
process.  When that happens, fcntl locks are inherited by the child.
The internal implementation of exec and spawn share a lot of code.  One
of the code bits is the function which hands over the fcntl locks from
parent to child.  So after spawn, the owner of the lock is not the
parent anymore, but the child process.  After the child process died,
the lock is abandoned and your 2nd test application rightfully claims
that the file region is unlocked.

I applied a patch which now differs between exec and spawn in the
function handling the inheritance of locks in the child.  If it has been
spawned, it does not take over POSIX locks anymore, but rather it just
gives them up in favor of the parent process.

The current snapshot at http://cygwin.com/snapshots/ does not have this
patch, but we will certainly produce another snapshot in the next few
days.


HTH,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJS+K6IAAoJEPU2Bp2uRE+gD2UP/RGGfiZBxJrSuHzhdodDBe//
m7Y8qkf3qh1epWzLqHCTsyosLv0XDwHX05FiirmuQJCKWJAddpYKe/Eo2H2vpf5c
Mdb7wTUkgjNbI/FATpK0cPOoIgXjU3oKdqlipXE21oDfv2BuAxnmG0Q3JbqUGSf8
zR3Jrjga6y8vU2XcPfYG8juHVMAIm7xENZA1mLt+dmVSJkHMYUVi5xqEWH9Wy0wL
VG08HCoc1q6zHXbH9f8HXlLtn0otPQcJQW4vdJ6Gf7FZ7iJqPY2BsMXnvlvCDtjF
G3+AlQ0VEONmii9blodmxOBErIotI5wemT4csFf1OgQFJgmJ09abdHGkYukHYKIb
YFm0RYw7YjYI4MyK1GjbA8GqarekrExCYQoo/DgAsKJySW60xFc1lr5GcQjYxZnh
DhtTPcEroA/guJ6MwbtfVyU6u8lpDuCVxczzULkY10+pBeJDwpIwA5nVr5Epxxy6
sHcpE6ZCX8zkWEXiOlRcPV68by3a8f63w+ndePEpq7iRgmxpZ/IcKfDdjmkEikz/
PSZ/2LBOrvn8zeSktMO2Kf3FznVS6UwsIFRZed8OXBIZxLGgYVdKODGG5Wp5VRU5
4QuDw7UZ0R1Bfi6sjt0HqC5wQ3NPbSC0CVBraPvVp0LBN3N9pEAdonh6Y8Qn+4l0
Gx9aUnJDZnltVzxKZyM4
=t3mL
-----END PGP SIGNATURE-----

--wRRV7LY7NUeQGEoC--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019