httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <>
Subject Re: 2.0: threading & i/o
Date Mon, 12 May 1997 18:06:48 GMT
Alexei Kosut <> wrote:

> On Fri, 9 May 1997, sameer wrote:
> > > abstraction supported rsthreads, pthreads, a skeleton frame that
> > > really spawned a child process, more?  Anyhow, there's plenty of free
> > 
> > 	I think being able to spawn a child is key for people who are
> > willing to deal with the RAM requirements of multiprocesses in order
> > to get the reliability of multiprocesses.
> Agreed. Also the simplicty of multiprocesses; if you're running a
> module that can't deal with multithreading (makes use of global
> variables, whatever), then threading simply isn't an option; you need
> to spawn a seperate process for each request. The thread abstraction
> in RST's apache-XX was also useful because it simplified threading;
> Apache (and especially an Apache module) doesn't need all the
> complexity of POSIX threads, and it's hard to implement all of that on
> some systems, anyway.

I see, so "rsthreads" was the abstraction, not a standalone threads
implementation?  I most certainly agree with everyone that
multi-process support cannot go away.  How do you think I feel about
mod_perl and the vast array of libraries that it can pull in?  :-)
I'm in the same boat as Rasmus here, we have no control over
libraries such as pg95 and msql.

The abstraction I've started does offer a simple interface.  More
important, it is one interface, no matter what's underneath:
POSIX1003.1c, POSIX1003.4a, forking/waitpid/etc, Win32 threads, etc.
Speaking of Win32 threads, umich's LDAP SLAPD server provides a layer
to wrap a pthreads interface around Win32 native threads, very nice,
I'm sure we can borrow it.  

> One option I believe we've discussed is keeping the current model; one
> process for each connection (it isn't clear to me that multithreading
> has great benefits over the current multiple-process model
> anyway. Someone more familiar with threads would be able to tell us,
> likely), but making use of threads within that process, for whatever
> purpose (and there are a number of them - including eventually

There are benefits to both models, if we can mix-n-match to get the
best of both worlds, that would be a big win.  In the corner I'm
coming from, threads are a must have for DCE integration, regardless
of performance.  Because DCE is so thread-centric, many pieces simply
won't work under the multi-process model.  


View raw message