You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dean Gaudet <dg...@arctic.org> on 1998/06/20 11:11:06 UTC
Apache 2.0, NSPR, C++, ...
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 NSPR.foo 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.
Dean
Re: Apache 2.0, NSPR, C++, ...
Posted by Wan-Teh Chang <wt...@netscape.com>.
Dean Gaudet wrote:
> > 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.
"nsprpub" was first released on 31 March 1998. Yes, nsprpubis a subset of the
complete nspr, but there is only one auxiliary
library that we cannot release, and the reason is that the copyright
of that library does not permit us to redistribute its source code,
just like Sun's copyright notice does not permit us to distribute
its JVM source code with Mozilla. I want to reassure
everyone that we didn't hide any "good stuff".
(The core nspr library is in mozilla/nsprpub/pr. The auxiliary
libraries are in mozilla/nsprpub/lib.)
On each platform, nspr may have more than one implementation.
In particular, on the major Unix platforms, nspr typically has
an implementation using only user-level threads, and an
implementation using native threads/pthreads.
Mozilla uses the user-level threads only implementation. The
reason is not for portability but to work around certain bugs
or constraints of X libraries. (I don't really know the details.)
Netscape's server products use the native threads/pthreads
implementation, which is the implementation we recommend,
and is the default build target.
Any new work we have done on the source code after
its initial release on 31 March 1998 has to follow the rules
of the Netscape/Mozilla Public License.
Wan-Teh
Re: Apache 2.0, NSPR, C++, ...
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On Mon, 22 Jun 1998, Dean Gaudet wrote:
>
> > > If you can also stomach the idea of using C++ as a "better way to keep
> > > lists of functions than C" then we're really cooking! (err, yeah, I'm
> > > talking virtual functions here).
> >
> > No you'll have to whack on me some more. It's best for you to introduce a
> > subtle bug that you know I'll track down (i.e. put it in vhosts and then
> > nobody else will touch it ;)... a subtle bug that when found I'll realize
> > "oh duh, virtual functions solve this problem!" ;)
>
> Well, IMHO, putting virtual functions in the Apache core itself (at least,
> right now) won't fix anything, and as you (Dean) made me painfully aware
> earlier this year, they aren't the fastest buggers in the world (can
> anyone say "Java"?). I mean, I don't see the need for polymorphism right
> now, not without a real OO redesign of the core code.
>
> On the other hand, the Apache modules are just crying out for it... the
> module_struct structure in particular strikes me as a place that tries to
> approximate polymorphic derived classes using a C language feature that
> isn't perfect for the task.
That's _exactly_ what I had in mind!
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: Apache 2.0, NSPR, C++, ...
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Mon, 22 Jun 1998, Dean Gaudet wrote:
> > If you can also stomach the idea of using C++ as a "better way to keep
> > lists of functions than C" then we're really cooking! (err, yeah, I'm
> > talking virtual functions here).
>
> No you'll have to whack on me some more. It's best for you to introduce a
> subtle bug that you know I'll track down (i.e. put it in vhosts and then
> nobody else will touch it ;)... a subtle bug that when found I'll realize
> "oh duh, virtual functions solve this problem!" ;)
Well, IMHO, putting virtual functions in the Apache core itself (at least,
right now) won't fix anything, and as you (Dean) made me painfully aware
earlier this year, they aren't the fastest buggers in the world (can
anyone say "Java"?). I mean, I don't see the need for polymorphism right
now, not without a real OO redesign of the core code.
On the other hand, the Apache modules are just crying out for it... the
module_struct structure in particular strikes me as a place that tries to
approximate polymorphic derived classes using a C language feature that
isn't perfect for the task.
Or whatever...
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: Apache 2.0, NSPR, C++, ...
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 22 Jun 1998, Ben Laurie wrote:
> OK, now we're talking! Note that in C++ it is possible to have two
> strchr()s - one const, one non-const, without having to mess with three
> zillion (oh, OK, I exaggerate - two in this case, but for strcmp() it
> would be four, and so on) different names for each function.
Right.
> If you can also stomach the idea of using C++ as a "better way to keep
> lists of functions than C" then we're really cooking! (err, yeah, I'm
> talking virtual functions here).
No you'll have to whack on me some more. It's best for you to introduce a
subtle bug that you know I'll track down (i.e. put it in vhosts and then
nobody else will touch it ;)... a subtle bug that when found I'll realize
"oh duh, virtual functions solve this problem!" ;)
Dean
Re: Apache 2.0, NSPR, C++, ...
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Sun, 21 Jun 1998, Ben Laurie wrote:
>
> > Good question: I'm only interested in exploring whether C++ is a
> > sensible option for 2.0 (or 3.0 or 2.26 or whatever). I only set up the
> > Apache++ list because I was approached by people too nervous to discuss
> > it here because of the amount of heat it generated.
> >
> > I'd like to see the concept explored but do not currently have the time
> > or energy to do it single-handed.
>
> Yeah I would like to see that too.
>
> > Whatever happens, I would like to see a nice C++ interface for 2.0, but
> > I suppose that is also in the air.
>
> I'm in favour of C++ being used as a "better type checker than C". If
> it's feasible. After finding that mod_usertrack bug that was a result of
> strchr() "losing" the const I'm sold on the idea. Maybe that means we'll
> need a few #ifdef __cplusplus sections in .h files which declare things
> slightly differently for C++ and for C... it's similar to the GNUC
> __attribute__s I've put in for printf-style warnings and whatnot.
OK, now we're talking! Note that in C++ it is possible to have two
strchr()s - one const, one non-const, without having to mess with three
zillion (oh, OK, I exaggerate - two in this case, but for strcmp() it
would be four, and so on) different names for each function.
If you can also stomach the idea of using C++ as a "better way to keep
lists of functions than C" then we're really cooking! (err, yeah, I'm
talking virtual functions here).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: Apache 2.0, NSPR, C++, ...
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 21 Jun 1998, Ben Laurie wrote:
> Good question: I'm only interested in exploring whether C++ is a
> sensible option for 2.0 (or 3.0 or 2.26 or whatever). I only set up the
> Apache++ list because I was approached by people too nervous to discuss
> it here because of the amount of heat it generated.
>
> I'd like to see the concept explored but do not currently have the time
> or energy to do it single-handed.
Yeah I would like to see that too.
> Whatever happens, I would like to see a nice C++ interface for 2.0, but
> I suppose that is also in the air.
I'm in favour of C++ being used as a "better type checker than C". If
it's feasible. After finding that mod_usertrack bug that was a result of
strchr() "losing" the const I'm sold on the idea. Maybe that means we'll
need a few #ifdef __cplusplus sections in .h files which declare things
slightly differently for C++ and for C... it's similar to the GNUC
__attribute__s I've put in for printf-style warnings and whatnot.
Dean
Re: Apache 2.0, NSPR, C++, ...
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> 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.
Good question: I'm only interested in exploring whether C++ is a
sensible option for 2.0 (or 3.0 or 2.26 or whatever). I only set up the
Apache++ list because I was approached by people too nervous to discuss
it here because of the amount of heat it generated.
I'd like to see the concept explored but do not currently have the time
or energy to do it single-handed.
Whatever happens, I would like to see a nice C++ interface for 2.0, but
I suppose that is also in the air.
Certainly the current thinking seems to be that NSPR is a good basis for
either a C or C++ 2.0.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/