Date: Thu, 16 Apr 1998 12:13:38 -0700 (PDT)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: NSPR/multithreading stuff
In-Reply-To: <Pine.LNX.3.96.980416131719.4647M-100000@ecstasy.localnet>
Message-ID: <Pine.LNX.3.96dg4.980416115422.9005C-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Well we can decide on it, but it shouldn't be locked in stone.  I'm
particularly enamoured of the POSIX API given that it is an existing
standard and already implemented in many places.  There may even exist a
WIN32 port of it, dunno.  It should serve as a model at any rate. 

So yeah, regarding my process model document.  The part I'm unsure I agree
with now is the existance of fibers.  Consider Solaris as a model. 
Solaris has a VERY NICE threading implementation that completely hides the
existance of "fiber-like" stuff behind the scenes.  You code to the POSIX
model and you get all the benefits I mention that a hybrid multi-thread,
multi-fiber model has. 

I know that the Linux folk will head this way when they finish stabilizing
the current threads (right now they're working on functionality and
correctness) -- all I'd have to do is show them a solaris threads port
running faster than a linux thread port on the same hardware and they'd be
off doing the work ;) 

Anyone familiar with FreeBSD, OSF/1, or HPUX threads want to pipe up? 

Now, since most everything regarding I/O will eventually be hidden behind
the BUFF interface (or its successor), I'm guessing that an aggressive
WIN32 port could hide the use of win32-fibers.  We can abstract the few
things that need abstracting later (opendir, stat, other misc things). 

If you think of threads as the next generation after multiprocess, fibers
are really the generation after that... but it's a generation that we
don't have to implement, as Sun has shown with Solaris it can be hidden in
the libraries.  It would save us a lot of time if we could just ignore
fibers.  So really, I'd like to drop fibers from the model.  And that
leaves us with processes and threads... which is exactly what POSIX
threads supports. 

We should put some icing on the pthread interface probably.  They need to
be integrated with pools.  I have no qualms about taking every
pthread_foo() function and calling it ap_pthread_foo() and inserting pools
where needed.  There's a very nice optimization that Ben Hyde and I talked
about a while back that makes it so that all threads get lock free memory
allocation almost all the time. 

I'm a tiny bit further on my linuxthreads problem, I realised this morning
that I'm probably screwing up the libc initialization with the fork() in
detach().  So I'm skipping detach() for now.  I also figured out I need to
set the TZ variable because glibc doesn't like my hybrid libc5/glibc2
system... still segfaulting under load, but the times in the log messages
are right.

BTW linuxthreads and posix threads differ slightly in a way that should
make it easier for me to get a port done, which is why I'm doing it.  On
linux, threads and processes and hybrids of the two are created with a
function called clone() that lets you choose which aspects of the task you
want to duplicate and which you share.  The current kernels don't allow
you to share pids between tasks very easily.  So in linuxthreads, each
thread has its own pid, which happens to double as its thread id.  You can
send signals to individual threads, each thread can have its own alarm,
and so on.  This makes it non-POSIX compliant, and this distinction will
go away some day when the kernel has better support for CLONE_PID.  But
right now, I was hoping it'd make my job easier. 

Dean

On Thu, 16 Apr 1998, Mark J Cox wrote:

> > Other modules will most definitely want to do this!  The PHP3 project is
> > in about the same state as Apache in terms of multithread support.  
> 
> Okay, looks like AOLserver had the same idea (but a long time ago!)
> 
> http://www.aolserver.com/server/docs/2.1b/html/v21-ap74.htm
> 
> I don't particularly like their function names though.  Can we decide the
> API now?  That would save everyone playing with multithreading stuff lots
> of time. 
> 
> Mark
> 
> 
>