Re: 2.0: threading & i/o

[Doug MacEachern <do...@opengroup.org>]

Alexei Kosut <ak...@nueva.pvt.k12.ca.us> 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
> HTTP/NG).

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.  

-Doug 

Re: 2.0: threading & i/o

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On Mon, 12 May 1997, Doug MacEachern wrote:

> I see, so "rsthreads" was the abstraction, not a standalone threads
> implementation?  I most certainly agree with everyone that

No, rsthreads was a standalone threads implementation. He had a
seperate thread abstraction system, which bore a striking similarity
to rsthreads (gee...), but also was implemented as pthreads, and as
forking not-really-threads.

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/