[PATCH] [BZ #18433] Check file access/existence before forking.

Szabolcs Nagy szabolcs.nagy@arm.com
Fri Sep 11 09:08:00 GMT 2015


On 10/09/15 22:45, navid Rahimi wrote:
> On Thu, Sep 10, 2015 at 10:56 PM, Phil Blundell <pb@pbcl.net> wrote:
>> On Thu, 2015-09-10 at 19:35 +0430, Navid Rahimi wrote:
>>> I think our main objection here is to avoid forking when there is no
>>> file.There is so many other variable for checking if execve is going to
>>> success or not.
>>
>> On the other hand, your patch will add an extra system call and
>> directory lookup to every successful posix_spawn() call, i.e. you are
>> optimising the failure case at the expense of the successful case.  It's
>> not at all obvious to me that this is a sensible thing to do.  Can you
>> explain your reasoning in a bit more detail?
>>
>> p.
>>
>>
>
> I agree with you completely about overhead and extra syscall , but
> there is no other option if we want to check fork. About optimizing

there are other options.

for example you can correctly check if execve returned
and report an error then instead of doing approximations
of the right check.

you can report the error through a cloexec pipe to the parent.

note that a correct posix_spawn implementation never uses
fork for QoI reasons (that's the point of posix_spawn, so
it works on nommu, large multi-thread applications etc.)
and vfork has the wrong semantics for c code so there are
other issues here.

> failure case , I would not call it optimizing , I returning correct
> error code and correct answer to caller at expense of one extra
> syscall overhead . Perfect Abstraction I think is the most priority of
> every project.Adding extra syscall will have overhead , but without
> that we are not reporting status correctly to caller.
>



More information about the Libc-alpha mailing list