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