From: rst@ai.mit.edu (Robert S. Thau)
Date: Sun, 21 Apr 1996 19:58:52 -0400
Message-Id: <199604212358.TAA26496@volterra.ai.mit.edu>
To: new-httpd@hyperreal.com
Subject: Re: API question
Sender: owner-new-httpd@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

  Forcing modules and libraries to be threaded as well.  Ack!  Not that I
  think it is a bad thing, just that it would be a lot of work.

Actually, there are some shades of gray.  My threads are non-preemptive,
meaning that once scheduled, they own the processor until they *explicitly*
give up control (either by invoking thread-blocking I/O, or by doing something
like waiting for a mutex lock to be available).  On the downside, this means
that if a thread does something which blocks, without having arranged to 
give up control and wait for completion, then every other thread in the
process is blocked along with it.  On the upside, however, this means that
you can use the facilities of libraries which are *not* thread-safe as 
long as you have control, and as long as you're careful to leave things in
a safe state when giving it up.

So, for instance, it ought to be perfectly fine to call strtok() to
parse a string, *if* you are careful never to allow other threads to
proceed (in particular, never to do I/O to a client) while you are in
the middle of parsing a string.  With strtok(), it probably isn't
worth the worry, but there may be other routines which take only
slightly longer and are definitely worth the trouble.

Of course, if the functions you're calling block often enough and long
enough to be a bother, you've got to do something about them --- DNS
lookups being the prime example.  I had to write code which contacts
the DNS server directly, using the Berkeley -lresolv routines to
format queries and inspect replies, and communicating with it in a
fashion that blocks only the calling thread.  Surprisingly enough,
this does seem to be fairly portable --- I've gotten it to work on
about ten different systems, including HP-UX, AIX and Ultrix (which
have a reputation as hard cases) --- but unfortunately it *won't* work
on systems where hostname resolution is available only through NIS.

Database lookups may fall somewhere in between these two extremes, and
I'm not at all sure exactly where that will turn out to be.  To put it
another way, it shouldn't be too hard to make a database gateway work,
but making it work *well* may be tricky.

rst