httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)
Date Thu, 18 Mar 1999 13:03:05 GMT

> > I would wish to keep portability a high factor, and it that case I would
> > _guess_ that the present apr implementation would be easier than NSPR.
> > Of course, a lot of work is already _in_ NSPR, so it's a double edged
> > sword :/
> 
> Yeah a lot of the little nice things are in NSPR, like an abstract time
> type and such... things which differ between unix variants in addition to
> win32.

Well, I have a VERY biased opinion, but I'll speak up anyway.

First of all, I think portability is an absolute must.  If apache-1.3
runs on a platform, than apache-2.0 (whatever that is) also needs to run
on that platform.  That is one of the reasons I would rather see a
hybrid server than a straight threaded server.  With a hybrid server, we
can get back to a process based server by just defining the number of
threads to be 1.  And, we can get a threaded server by defining the number
of processes to be 1.

One of the goals of the current apache-apr code, is to abstract out
anything that is threaded, and allow it to be written in a non-threaded
way.  The accepting code is a prime example.  We are currently working on
getting it removed from http_main, so that if you don't have threads, you
compile a different file into the server.

Having said that I am a very BIG fan of the apr work.  But I am a fan of
it because I am selfish.  I think it would be interesting work, and I am
looking forward to doing it.  At the same time, I realize that most of the
work has already been done for us by NSPR.  As much as I hate to say this,
I would like to see us use NSPR provided we keep a couple things in mind.

1)  The license has got to be changed to something acceptable by everybody
soon.  If we wait too much longer, it will just be that much harder to
putthe portability layer into the code.

2)  I am no expert on licenses, and I haven't read the new one, but I
think it is important that other platforms be able to implement a sub-set
of the NSPR API's.  This allows platforms without threads to implement
everything except the threading API's, and just put in no-op code for
those calls, and still be able to run the server.

3)  If #2 is allowed, than we will need to specify which API's are
absolutely required to use the server, and which can be no-op's.  For
example, you won't be able to run the server with the File I/O API's
implemented properly.

I would also like to make sure that the mozilla people are really
interested in our changes to NSPR.  ANY PR layer has the potential to hurt
our performance just because it is adding a function call to all system
calls.  There is some trickery that we can do within the PR to minimize
that penalty.

For example, the File structure should know more about itself than either
File Pointers or File descriptors do.  I believe a File structure should
know which file it points to, and all of the Stats for that file (user,
group, permissions, etc).  If we can get this information on a file we
are going to serve when we first open the file, we most likely do not ever
have to grab that info again.

If the NSPR folks are willing to seriously look at any improvements we can
make, than I say lets not re-invent the wheel.  If any of the statements
on the above wish list are not true, then I say lets take some time and
write apr from scratch.  If NSPR is released with an acceptable license,
we could even take some ideas from them.  I will also mention that I wrote
about half the file I/O, and test routines for them, in about two days.
And I didn't work more than an an hour or two on either of those days on
apr.  And, about a day after I posted my code to apache, there was a BeOS
guy who had taken my code and modified it to make it run on Be.

I just don't think that if mozilla doesn't come through for us, it will be
a huge deal to write the PR layer ourselves.

All my own opinion of course.

Ryan


_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message