httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <>
Subject Re: API question
Date Mon, 22 Apr 1996 16:29:49 GMT
In reply to Robert S. Thau who said
>   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 

Hmm, what exactly does this model gain you? I'd have thought that the
current pre-forking model would give better performance than anything
non-preemtive. The extra overhead of copying the data area isn't that
high since it's an up-front event most of the time. The only difference
between a non-preemtive threaded server and a single process server is that
the threads have access to the parent's data area. Other than that it *is*
a single process in effect since it can only do one thing at a time.

Hmm, ok, I see one thing, if you write the thing carefully you can
voluntarily deal with more than one connection request by giving up
control of a thread. I guess I'll have to take a look at it when it's
ready. You could do this without threads though by simply queuing
requests and changing a status flag as you perform certain steps.

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

This isn't as big a problem as people are making out. If something is
not thread-safe you simply put locking around it. Obviously, if there's
a lot of such code then all the threads get bottleknecked on the locks
but it will work and as a solution for compiling in database gateways
and similar large external packages it's the simplest and probably the
best solution.

  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

View raw message