Re: Potential new syscall

[Mouse <mouse%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.
> [...]
> Having the mechanism available for testing (even if it was not
> committed to the standard NetBSD sources (yet?))

Certainly not yet; at present, it exists on only one machine.  I don't
run -current, so it's not appropriate for me to try to put it into
-current, but I would be fine with someone else doing so.

The "one machine" that has it now is running (my evolution of) 5.2.  On
my morning commute today I tested it, and it works, for very
rudimentary smoke-test values of "works".

> 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.

Which of course is why vfork exists at all. :-)

> You are of course correct that there is a very limited set of
> functions possible in a vfork()'d child -

I disagree.  The set of functions usable in a vfork()ed child is
actually quite wide on most systems - but you have to know a good deal
about the implementation of vfork() and the functions in question to
know which ones are safe and why, and how to safely use the ones you
can.  (For example, on the 5.2 I'm working on, I can printf() from the
child just fine, provided I fflush() at suitable times so that stdio's
internals don't get confused.)  The set of functions you can use
narrows as you care about wider and wider portability, to the point
where, if you're trying to be portable to anything POSIX, vfork() is
basically useless (because you can't do any of the usual post-fork
pre-exec prep).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B