X-Recipient: archive-cygwin@delorie.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@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.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@cygwin.com>
To: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>
Cc: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7
Message-ID: <20190208130635.GO13951@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: Michael Haubenwallner <michael.haubenwallner@ssi-schaefer.com>,	cygwin@cygwin.com
References: <announce.20190205151855.GD16130@calimero.vinschen.de> <02da4eeb-fcce-b1bc-e6eb-68ff3ec0cf74@ssi-schaefer.com> <20190207182735.GG13951@calimero.vinschen.de> <8a2f041f-f8f7-6e17-5d97-5a168440009b@ssi-schaefer.com> <20190208113158.GH13951@calimero.vinschen.de> <17e339bb-2115-bf22-7291-04215aab3150@ssi-schaefer.com> <20190208122126.GM13951@calimero.vinschen.de> <20190208122338.GN13951@calimero.vinschen.de> <b07e6ba2-0ce0-4662-7a02-bda6ce3b0108@ssi-schaefer.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--
