On Feb  8 13:52, Michael Haubenwallner wrote:
> 
> 
> 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.
> > 
> > Does that help, by any chance:
> > 
> > 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 = NULL;
> > +    h = INVALID_HANDLE_VALUE;
> >  
> >    /* Setup our write end of the process pipe.  Clear the one in the 
> > structure.
> >       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 = create_cygwin_pid ();
> >        flags |= PID_NEW;
> >      }
> > +  else if (h == INVALID_HANDLE_VALUE)
> > +    h = NULL;
> 
> No, because cygheap->pid still is the parent's pid here, not the new child's 
> one.
> 
> How should the child be informed at all about the new cygpid value generated 
> 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

-- 
Corinna Vinschen
Cygwin Maintainer

Attachment: signature.asc
Description: PGP signature

Reply via email to