httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@opengroup.org>
Subject Re: threads abstraction (was: Apache Server Contribution)
Date Thu, 12 Jun 1997 13:29:49 GMT
Paul Sutton <paul@ukweb.com> wrote:

> Or it may delay Apache NT while some new feature that were supposed to be
> made into 2.0 (eg multithreading) are added to 1.3 instead. Or do we just
> accept Ambarish's implementation of threading as it is, and now make it
> work on Unix as multithreaded until 2.0? If multithreading is to work on
> Unix we'll have to spend some time abstracting the threading API to POSIX.

A few weeks ago I thought the athreads abstraction was ready to go.  I
can take most of the examples from the ora pthreads book,
s/pthread/athread/g, then they run on unix (POSIX1003.1c and
POSIX1003.4a (DCE Pthreads)) and on NT.  I found it's not quite so
simple trying to go in the other direction.  When I got my hands into
Ambarish's port and I find some win32 stuff that doesn't map cleanly
to the pthreads model.  Of course, this is not Ambarish's fault, it's
obvious to me now, M$ API design was implemented such that developers
would need to sink more money into all their books, toolkits, etc. :-0 

But, it's close and I'm willing to take the first crack at a single
source implementation that runs on win32 and unix (threads or
multi-process) using this abstraction.  However, I too see apache
win32 as a priority, I'd very much like to see that get out the door
first and then work from that there.  For full DCE integration (the
reason I've started digging to all this), other abstactions are
required, i/o (sfio or some such) and transport (need to use RPC
instead of raw socket calls).  DCE also requires a client-side piece,
since browser plugin APIs don't give you access to the protocol and
transport layers, Apache will be used as a local client-side proxy.
Win32 support is a must for client-side support.  

-Doug

Mime
View raw message