From owner-freebsd-hackers  Tue May  9 17:28:27 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id RAA01089
          for hackers-outgoing; Tue, 9 May 1995 17:28:27 -0700
Received: from netcom14.netcom.com (root@netcom14.netcom.com [192.100.81.126])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA01083
          for <freebsd-hackers@freebsd.org>; Tue, 9 May 1995 17:28:26 -0700
Received: from localhost by netcom14.netcom.com (8.6.12/Netcom)
	id RAA29299; Tue, 9 May 1995 17:01:50 -0700
Message-Id: <199505100001.RAA29299@netcom14.netcom.com>
To: terry@cs.weber.edu (Terry Lambert)
cc: taob@gate.sinica.edu.tw (Brian Tao), nc@ai.net,
        Arjan.deVet@nl.cis.philips.com, freebsd-hackers@FreeBSD.org,
        Guido.VanRooij@nl.cis.philips.com
Subject: Re: Apache + FreeBSD 2.0 benchmark results (fwd) 
In-reply-to: Your message of "Tue, 09 May 95 15:28:07 MDT."
             <9505092128.AA19726@cs.weber.edu> 
Date: Tue, 09 May 95 17:01:38 -0700
From: Bakul Shah <bakul@netcom.com>
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> > > The correct term for "pre-forking" is "spawn-ahead".
	...
> >     I was always under the impression that the creation of another
> > process is called "forking" under UNIX and not "spawning (isn't that
> > VAX-speak?).

> Nope; just generic CS-speak.

`spawning' is approx. equal to fork + exec, not just fork.
A system that provided spawn can do certain optimizations
(with a loss of some flexibility).  I have never heard of
pre-spawning.  Are you trying to, er.., spawn new words?

> >     What, have a specially-compiled kernel that can fork off httpd's
> > in no time at all?

FYI, this has been used in atleast one system.  The kernel
kept a number of server processes.  Under heavy load more
processes were forked off, under light load extra idle
processes were killed off.  A variation of `select' to do
this may be something worth investigaing.  Typically a
server process does a select to wait for a request to
arrive.  If you want to provide more threads of control
dynamically, and these threads agree to cooperate, you would
use this hypothetical `server-select'.  Once some parameters
are set, the kernel would dynamically add or remove threads
depending on traffic (but only in serever-select).

> If you don't convert the I/O requests, then you aren't really a
> multithreaded server at all, since a blocking request in any thread
> of control can block other threads of control that would otherwise
> be runnable.

Correct.  Select() in this context is suitable for servicing
lots of `short term' requests, not long lasting ones.  So
long requests should handed to another thread.  But doing so
in Unix eats up more time.

> The other alternative is a Non-Blocking I/O Dispatch model, where you
> guarantee that you will not attempt potentially blocking operations
> in the context of a dispatched thread of control.     ...
>               ...                     Depending on what you do with
> this model, you can actually end up with some very complex finite
> state automatons to get the desired behaviour.

Right.  I think `asynchronous' IO probably provides the best
performance with a moderate increase in complexity.  Alas,
we can't do that under Unix:-(  Any thoughts on a decent
implementation of that?

--bakul