Re: Potential new syscall

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 2 Apr 2018 19:29:25 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <201804022329.TAA19246%Stone.Rodents-Montreal.ORG@localhost>

  | Basically, what I want is a syscall that a vfork()ed child can call to
  | have the unsharing effects of execve(2) or _exit(2)

I have considered (and think I mentioned on some list some time
ago) the same capability to improve sh performance.

But as I don't want to think about pure performance changes until
I am happy that the functionality is as correct as I can make it,
pondering its usefulness is as far as I went so far.

Having the mechanism available for testing (even if it was not committed
to the standard NetBSD sources (yet?)) would be a real help, when it
comes time to evaluate whether that method, or converting sh to use
posix_spawn (an alternative that was suggested, but which I kind of
dread - considering the amount of work that would be involved) would
produce the best results.

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