httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Skolnick" <cl...@steam.com>
Subject RE: Thread/Process model discussion.
Date Fri, 29 Jan 1999 20:04:30 GMT
I'll only touch the flame bait here, indeed, it would be a rock of a server.
:)

We need to consider 3 types of multi-process threads.

The first is a pure userland thread, which will share an interface into the
kernel with all other user threads.  In other words when I/O is done, only
all threads stop waiting for the kernel to complete the request, if it is
blocking. If you are lucky you can multiplex n kernel threads over m user
threads.  This type of thread is really cheap to create and run, pretty good
for compute only functions.

The second level of thread is a userland thread with a corresponding kernel
thread.  When it goes into the kernel it will only block itself.  These
threads require more data structures so the are a little more expensive, but
they are great for I/O.

The last level is the process level, you know fork(), get your own address
space which may or may not share address space with your parent.  This model
is expensive.

If any OS only provides the first and third type of threads, we must go to
the multiprocess model or our server will only be able to have one
outstanding blocking I/O request.  This would be very bad!

If the OS provides the second type of thread, sure we could cram all threads
into the same process and be happy.  But as mentioned before, it would still
be more robust to also use multiple processes and more importantly it may
get you beyond per process thread and file descriptor limits.

Cliff

> > I like the hybrid process/thread architecture.  In a purely threaded
> > environment a fatal error in a loaded module will take down your server.
>
> Not if the server's written in C++ (as Apache should be) and you use
> exception handling.
>
> Yes, I know this resembles flame-bait, but it's really not.  I'd
> love to see
> a pure C++ implementation, including a new module API (that resembles the
> Java servlet API perhaps).  If the overhead/baggage/resource
> consumption of
> the multiple-process model is acceptable, then a bit of C++ language
> overhead ought to be acceptable too.  You'd get a more robust server
> (exception handling, better resource leak prevention (via object
> destructors)), and IMO it would be easier to extend the platform
> (imagine a
> "module" base class ... just derive from it, override a few functions, and
> tada, a new module).  Yes, all this *can* be accomplished (except for
> exception handling) in straight C, it's just easier (to me anyway) in C++
> w/the OO model.
>
> C++, OO model, lots of STL, and maybe some good platform specific
> performance tweaks (like asynchronous I/O w/completion ports on NT) - now
> that would rock!  :)


Mime
View raw message