httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 16:28:01 GMT


On Mon, 19 Apr 1999, Nitin Sonawane wrote:

> example of the open system call. Wouldnt the kernel block you while each
> directory in the path is being read, searched, the inode looked up, and
> the inode read in.

Yup. 

And then imagine it running on NFS.  Which does occur in the real world, a
lot.

And before someone says "cache it all": get your head out of the
benchmarks. 

And before someone says "async i/o": gee, I don't see an aio_open. 

And before someone says "use multiple i/o threads like squid does": gee,
why don't we just use threads? 

And before someone says "use multiple processes like zeus does": gee,
we're already planning on that.  If you think a single process select
based threading model is better, then you can build with mit-pthreads.

It all comes down to simplicity.  Callback/event-loop programming is not
immediately obvious to all programmers.  If that's the model we used, it
would become much more difficult for third party folks to integrate. 
callback programming is such a different model that many third party
libraries which do i/o can't be used.

yadda yadda. 

This is all in the archives somewhere.  It repeats about once every other
month or so. 

Repeat the mantra:  correct first, fast second.  If you think you can do
better I'd love to be proved wrong.  But if all you want is to max out a
benchmark, then I think you're taking the wrong approach.

Dean



Mime
View raw message