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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=OmqHPDS6WEib/BRaScGl2u8oCsndiYrZSWl5btJkCdtaUSesJisCT
	NLsEe3mHJpSXGRrg6cjoaqd4kRUyjwp48+4SV0ZSSZQpkDwN0oSFahQMAFrsQTNo
	fTTMuJxHX4TF+0Nzh+QhaauJ94SqxP6zxzYUBaTiUXgEuf9UTRD+wA=
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:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=tEO0GfkHUjKkH2PHQQwCvRFUVZ8=; b=xUhikjpCdCv7nXJmDnFNGpALhoYE
	06/t+SJZgwPL/mP8/WpwylkX+XsVyay14phqGJ7X1F/lnEbxEwEfx9KDTvplig+c
	7PAX/WE5AN33z49Xpe3MUV1lHBfTfRxiRBtjJ1aGNBWgIMui+qrwLHPnJ/qEAs5l
	HliLSFDnTWK0SWw=
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-Spam-SWARE-Status: No, score=-125.4 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=
X-HELO: mout.kundenserver.de
Date: Fri, 8 Feb 2019 14:06:35 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: Michael Haubenwallner <michael DOT haubenwallner AT ssi-schaefer DOT com>
Cc: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7
Message-ID: <20190208130635.GO13951@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: Michael Haubenwallner <michael DOT haubenwallner AT ssi-schaefer DOT com>,	cygwin AT cygwin DOT com
References: <announce DOT 20190205151855 DOT GD16130 AT calimero DOT vinschen DOT de> <02da4eeb-fcce-b1bc-e6eb-68ff3ec0cf74 AT ssi-schaefer DOT com> <20190207182735 DOT GG13951 AT calimero DOT vinschen DOT de> <8a2f041f-f8f7-6e17-5d97-5a168440009b AT ssi-schaefer DOT com> <20190208113158 DOT GH13951 AT calimero DOT vinschen DOT de> <17e339bb-2115-bf22-7291-04215aab3150 AT ssi-schaefer DOT com> <20190208122126 DOT GM13951 AT calimero DOT vinschen DOT de> <20190208122338 DOT GN13951 AT calimero DOT vinschen DOT de> <b07e6ba2-0ce0-4662-7a02-bda6ce3b0108 AT ssi-schaefer DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="LQAwcd5tHl0Qlnzi"
Content-Disposition: inline
In-Reply-To: <b07e6ba2-0ce0-4662-7a02-bda6ce3b0108@ssi-schaefer.com>
User-Agent: Mutt/1.10.1 (2018-07-13)

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

On Feb  8 13:52, Michael Haubenwallner wrote:
>=20
>=20
> On 2/8/19 1:23 PM, Corinna Vinschen wrote:
> > On Feb  8 13:21, Corinna Vinschen wrote:
> >> On Feb  8 12:51, Michael Haubenwallner wrote:
> >>>
> >>> For now it seems like there's an inconsistency with PIDs:
> >>> A first process PID 100, receives PID 101 from spawn(),
> >>> but in the new process getpid() returns 102:
> >>>
> >>> $ ./dospawn /bin/bash -c 'echo $$'
> >>> 12625
> >>> waitpid: pid 12624 status 0x0
> >>
> >> Oh, hmm.  If you call spawnve, rather than execve, a new child pid
> >> is generated in spawnve, rather than just keeping the callers pid.
> >>
> >> However, apparently the child invents its own pid in pinfo::thisproc
> >> after being spawned.  But actually this should only occur for forked
> >> processes aore processes started from non-Cygwin parents.
> >=20
> > Does that help, by any chance:
> >=20
> > diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
> > index 78506d43de29..0b274287d9f6 100644
> > --- a/winsup/cygwin/dcrt0.cc
> > +++ b/winsup/cygwin/dcrt0.cc
> > @@ -656,7 +656,7 @@ child_info_spawn::handle_spawn ()
> >        !DuplicateHandle (GetCurrentProcess (), moreinfo->myself_pinfo,
> >  			GetCurrentProcess (), &h, 0,
> >  			FALSE, DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE))
> > -    h =3D NULL;
> > +    h =3D INVALID_HANDLE_VALUE;
> >=20=20
> >    /* Setup our write end of the process pipe.  Clear the one in the st=
ructure.
> >       The destructor should never be called for this but, it can't hurt=
 to be
> > diff --git a/winsup/cygwin/pinfo.cc b/winsup/cygwin/pinfo.cc
> > index 445bd35b224e..d10c4fc4580c 100644
> > --- a/winsup/cygwin/pinfo.cc
> > +++ b/winsup/cygwin/pinfo.cc
> > @@ -62,6 +62,8 @@ pinfo::thisproc (HANDLE h)
> >        cygheap->pid =3D create_cygwin_pid ();
> >        flags |=3D PID_NEW;
> >      }
> > +  else if (h =3D=3D INVALID_HANDLE_VALUE)
> > +    h =3D NULL;
>=20
> No, because cygheap->pid still is the parent's pid here, not the new chil=
d's one.
>=20
> How should the child be informed at all about the new cygpid value genera=
ted in
> parent's child_info_spawn::worker() ?

I just realized this myself.  The old method creating Cygwin pids just
fetched the pid from GetCurrentProcessId(), which was right for spawned
(but not execed) processes.  For the new pid we might have to give this
to the child via child_info_spawn.


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--LQAwcd5tHl0Qlnzi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxdftsACgkQ9TYGna5E
T6BvIg//awSoSeWhbq0rCTtNlo+SBm7c+djs4e0n8BMgz40eKwsJWupSp3HTHjmJ
dX2rBieErEFp/IbbMTM1No+JyRtBFgtC8GoL/mO6aaZpumQ67i5Vws8pxvwNtsDs
ROpqLofJyG/jGwTOWMfMjROqMwToah8nyU9PvZ88zsvOeDWhSJ1XrcZfp69iitmR
zzC1CgvhQajuuvQZnP9P4TbUt+tiNzHtu8VFBdsZ/yEW1LzPF09o/giBBHs8Z7vQ
0+tHhJaaq8S/WduSo6J0ULL0zQFVY5QaBBsSmHBhyPQ+UTmmKyy1e/nbR8P8Uy4Q
B2/kRQTQP5PfsCdvCIGOih82URKExaD0R2Fkuizz1jNt9vtlw6ttbyNgrSetHbsx
1KfdyllM8Wmmp4q9oI71/75xVicIshTsgLFzt4+bctEHGKZnDbg+EkFJD/FT1MG8
H50AMwc0IczqqTLi5sh1//g/45TGQnUKhFXPsibJstYRGuGSXNmETe5sad1qkJfj
WeCvgfTHE7FoY0LFzEg4QSo7jq6kQRvZ6ph2oPwKj2uti4n6yyODP/nhTXRc/VDN
z9jI0NWzXFtg5X7S9XwBFaB3Agaq2nYGiIhxepUZ+Owqv7PDGGQEouGo+a5kMM7M
M2pzfg4acbLNvbzJjy/077EBnq1U79QLViyoLonMgSEpqntbqE4=
=tg3U
-----END PGP SIGNATURE-----

--LQAwcd5tHl0Qlnzi--