On Tue, Aug 21, 2018 at 12:46 PM, Nathan Sidwell <nat...@acm.org> wrote:
> On 08/21/2018 03:04 PM, Ian Lance Taylor wrote:
>>
>> On Tue, Aug 21, 2018 at 11:15 AM, Nathan Sidwell <nat...@acm.org> 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(), _exit ()' a conformant program
> cannot tell whether it's fork-like or not. However we're already violating
> that constraint by dinking environ and calling close & write [in ways that
> are ok regardless of a fork-like attribute]. I see the man page says 'The
> requirements put on vfork() by the standards are weaker than those put on
> fork(2), so an implementation where the two are synonymous is compliant. In
> particular, the programmer cannot rely on the parent remaining blocked until
> the child either terminates or calls execve(2), and cannot rely on any
> specific behavior with respect to shared memory.'
>
> pants. I suppose we could add an autoconf test to probe whether the child
> and parent are serialized or not. that may or may not be simpler than ...
>
>>> The error behaviour if that program fails to be exec'd is confusing --
>>> there's an error about the exec failing but it's not attached to location
>>> information and the like, then there's a much more obvious error about
>>> communication failing. I found it confusing the first time I tripped
>>> over
>>> it (and I was writing that bit of the compiler :)
>>
>>
>> Is there any reason we couldn't fix that without relying on the odd
>> behavior of vfork?
>
>
> Maybe, ideas? (but this seemed the simplest way for me to get it to do what
> I wanted :)
The usual technique for better error handling is to open a pipe before
the fork, mark the pipe as close-on-exec, and have the child write
error information to the pipe. The parent can then read from the
pipe; if it reads nothing, then the pipe was closed by the exec and
all is well.
Ian
