tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Potential new syscall



On 03.04.2018 04:08, Robert Elz wrote:
> Kamil - "just use fork" is a very common response, but no matter how
> fork gets implemented, vfork() when used correctly always performs
> better by huge margins.   You are of course correct that there is a very
> limited set of functions possible in a vfork()'d child - which is why the
> function proposed by Mouse would be useful - currently sh limits its
> use of vfork() to the times it is very unlikely any of those will be be
> needed, and uses fork() other times (costing performance if it was too
> conservative) - and when the vfork() is attempted, and it turns out
> something needs doing which won't work, the vfork()'d child (and whatever
> work it had already done) is simply abandoned and it is all done again
> after a fork() - also costing performance.   The ability to just convert a
> vfork() into a fork() would avoid the waste in the latter case, and also allow
> far more agressive use of vfork() to help avoid the former losses.
> 
> kre 
> 

From the GDB protocol point of view, this syscall could be handled
flawlessly (no API changes to ptrace(2)) and it could reuse operation's
name: vforkdone(2).

I think there is needed prior verification of its stability and
benchmarking before the final decision.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index