Re: [Nmh-workers] vfork()

[Robert Elz]

    Date:        Sat, 24 Dec 2011 22:42:38 -0500
    From:        address@hidden
    Message-ID:  <address@hidden>

  | fork() should be almost as cheap as vfork() on any system that has a
  | sane memory manager that does copy on write of the memory.

On NetBSD, all the measurements (every time this comes up) show
vfork() outperforms fork() by a fairly large margin - but it matters
most for large processes, vfork() avoids the costs of establishing
a new process context, which is not cheap on many systems (even pc's).
It also avoids cache flushes needed when switching processes.

However I doubt that nmh is either big enough, or forks enough, for it
to make a difference anyone would be bothered by.

  | We don't do any vfork() without an immediately following exec*() call,
  | do we?

One would hope not, as that is what vfork() is intended for - to avoid the
cost of setting up a whole new process structure, only to tear it all down
again when the exec follows as (almost) the next syscall (usually just file
descriptor operations intervene).   Just borrowing the parent address space
is a fairly big win (even with copy on write, all the page descriptors still
need to be set up).

kre