httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Apache 2.0, NSPR, C++, ...
Date Sat, 20 Jun 1998 09:11:06 GMT

On Fri, 19 Jun 1998, Rasmus Lerdorf wrote:

> I think everybody has been avoiding this can of worms.  But it needs to be
> discussed.  To me the biggest question is whether your apache-nspr and
> Ben's apache++ (or whatever it is known as) can co-exist or do we have to
> decide on one over the other?  

NSPR could be used with C++ ... Ben can correct me, but I think what he
wants to do with apache-plusplus is to develop something that is
distinctly C++ and still highperformance/etc.  I don't know if that's on
the 2.0 time frame or not.  The list has been dead lately.

> I haven't looked closely enough at the nspr code to figure out what the
> thread-abstraction is going to do to my module architecture.

NSPR has multiple models of operation... and each interacts with third
party stuff slightly differently.  (This is just for Unix, NT has no
problems/caveats that I'm aware of.)  In theory, and I haven't verified
this completely, if you use NSPR as a set of wrappers for pthreads then
you can interact with any thread-aware/thread-safe library without
trouble.  In this case it's fine for any thread to block on i/o because it
is a pthread and pthreads are allowed to do that. 

If you use NSPR in its most portable form -- where it uses no native
threads, then third party libraries can't be used unless they do no I/O. 
They have to be ported to NSPR in order for things to work right with I/O.

>From looking at the library I've been pretty happy that both forms should
work on any unix with pthreads.  The portable form should work on
essentially any unix -- although I can imagine running into kernel bugs
with select/etc.

> Basically, since I don't see any other alternatives we may as well move
> forward and say that apache-nspr is the basis of Apache2.  

There are other alternatives, I'm just not as impressed with them.  As far
as I know, no other C threading abstraction has an initial set of ports so
large.  NSPR works already on 20 some odd unixes, plus WIN32 (plus mac and
win31 I suppose, with caveats).  I believe IBM has an OS/2 port that isn't
released, although there are groups working on a free port.  There's an
amiga port under way...  (These are actually ports of mozilla, NSPR will
probably be finished early on.) 

> One really ignorant question though.  Is the NSPR code the same code
> Netscape uses in their Enterprise Server product?  If so, I am a tad weary
> because I have had loads of reliability problems that look like threading
> problems to me with those servers.

>From what I understand (the netscape guys are here on new-httpd still I
think so they could answer better), NSPR in some form is used in their
enterprise server.  But I don't think it's the same library that they
released -- the released one is "nsprpub", for public I presume.

Reliability is something we can solve though, if in fact it is a problem. 
If I just look at the library as an abstract interface to I/O, threading,
and other OS primitives I see nothing that scares me.  I see why a lot of
things are the way they are... and I can envision how the under workings
should work.  I have looked at the under workings and the code style is
very pleasing.  It is an excellent piece of work. 

It's the sort of thing that I dreaded we would have to write.  There are
holes in NSPR's coverage of portability issues.  I mention the ones I've
run into in the README.NSPR and files in the apache-nspr tarball. 
Some of them make sense to solve within NSPR, and some make sense to solve
in apache.  (Some examples are filename manipulation, user/group/auth
details, some missing pieces in process creation...)  I'm excited about
using and extending NSPR to meet our needs. 


View raw message