httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: NSPR (was Re: cvs commit: apache-apr/pthreads/src/main http_main.c)
Date Sun, 21 Mar 1999 17:09:10 GMT

On Thu, 18 Mar 1999, Ryan Bloom wrote:

> 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.

It almost doesn't matter if the NSPR folks are interested in our changes
-- it's an open license.  At any rate they've already indicated they're
interested in our changes -- and have accepted at least one change; and
have commented on the acceptability of a few other proposed changes.

BTW, having looked at the NSPR API I was able to convince myself that it
could be implemented with a minimum of fuss, and provided all the
necessary abstractions for the optimizations I could forsee.  And having
looked at the code I was happy it was implemented in a clean manner -- and
I could see where I would want to tune it.  I may have missed some things. 
But to be honest, if netscape finds it fast enough to use for their web
server, I don't see why we'd be concerned. 

> 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.

Not that I agree or disagree, I just don't see where this helps.  Apache
never uses fstat(), which is the only thing you'd be optimizing here.  I'd
rather spend time optimizing stuff which actually occurs than adding

And even if apache did use fstat(), it should be cheap.  If it isn't then
your operating system has more problems.  It should be essentially the
same cost as a no-op system call... all it has to do is an array index,
and a pointer indirection or two. 

> 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.

Right, we just have to do it completely.  We can't just stop with
abstracted threads... we need abstracted sockets and files, times, network
address manipulation and lookup, ...

Yes APR can solve all the problems too.  And it is fun to have complete
control over the code... and it's way cool that IBM is sponsoring it. 
It'd just be nice though if we didn't have two open source portability


View raw message