Web lists-archives.com

Re: [ANNOUNCEMENT] TEST: Cygwin 3.0.0-0.7

On 2/8/19 2:28 PM, Corinna Vinschen wrote:
> On Feb  8 14:06, Corinna Vinschen wrote:
>> 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:
>>>> [nope]
>>> 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.
> This works for me, can you test this, too, please?

Looks good to me as well, I'm going to start my hours running use case now.

> I pushed your forkable branch to master, btw.  Would you mind to do the
> honors in the ;rease notes at cygwin/release/3.0 and doc/new-features.xml?

Ok, just preparing the tests first. Thanks a lot!


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