[uClibc]Re: system.c patch?

Miles Bader miles at lsi.nec.co.jp
Tue Jul 30 01:48:27 UTC 2002


On Mon Jul 29, 2002 at 04:57:22PM +0200, Tobias Anderberg wrote:
> I.e. doesn't it make more sense to use fork() if we don't have
> vfork() _or_ we have a mmu? I mean, if an mmu is available, fork is
> preferred over vfork, even if it exists, right?

Not as far as I know -- for something like `system', which always does
fork/exec, it seems that vfork should always be more efficient than fork.
[Even though MMU tricks can make fork pretty fast these days, you still
have to pay some cost for page-table twiddling, though in a Mach-derived
VM system like modern BSD systems, this cost can be very low indeed.]

Maybe there are system-specific issues I don't know about though (for
instance I'm not sure what the `Signals are not absolutly guarenteed
with vfork' comment in system.c means).

Erik Andersen <andersen at codepoet.org> writes:
> Hmm.  Perhaps it would be better then to use:
>     #if ! defined __NR_vfork && ! defined __UCLIBC_HAS_MMU__ 

That would mean that a system _without_ vfork, but _with_ an MMU, would
still try to use vfork, which would fail, right?

Why not just:

  #ifndef __NR_vfork
  #define vfork fork
  #endif

-miles
-- 
We live, as we dream -- alone....



More information about the uClibc mailing list