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!
/haubi/
--
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
