On Tue, Aug 21, 2018 at 12:46 PM, Nathan Sidwell wrote:
> On 08/21/2018 03:04 PM, Ian Lance Taylor wrote:
>>
>> On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell wrote:
>
>
>> OK, but what about a system that does
>>
>> int vfork() { return fork(); }
>>
>> ?
>
>
> Isn't such a system just buggy? H
On 08/21/2018 03:04 PM, Ian Lance Taylor wrote:
On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell wrote:
OK, but what about a system that does
int vfork() { return fork(); }
?
Isn't such a system just buggy? Hm, apparently not. Because of the
requirement the user just calls 'exec(), _exi
On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell wrote:
> On 08/21/2018 12:37 PM, Ian Lance Taylor wrote:
>>
>> On Tue, Aug 21, 2018 at 8:03 AM, Nathan Sidwell wrote:
>>>
>>>
>>> 1) If we know we're using vfork, we can tell the parent directly via the
>>> current stack frame and suitable use of v
On 08/21/2018 12:37 PM, Ian Lance Taylor wrote:
On Tue, Aug 21, 2018 at 8:03 AM, Nathan Sidwell wrote:
1) If we know we're using vfork, we can tell the parent directly via the
current stack frame and suitable use of volatiles.
I'm pretty reluctant to rely on this special behavior of vfork.
On Tue, Aug 21, 2018 at 8:03 AM, Nathan Sidwell wrote:
>
> 1) If we know we're using vfork, we can tell the parent directly via the
> current stack frame and suitable use of volatiles.
I'm pretty reluctant to rely on this special behavior of vfork. A
system could plausibly #define vfork fork and
This is the second patch for pex-unix's child spawning. Right now, if
we manage to (v)fork, but the execvp fails, we use write to emit an
error and then _exit. The parent discovers the child failed when trying
to communicate or wait for it. This can be improved in 2 ways.
1) If we know we'r
