httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Sonawane <nsonaw...@infolibria.com>
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 23:14:33 GMT
> 
> > I dont mean to get into a flame war but rather a brainstorming of 'why
> > would event driven servers ever perform better than a
> > multiprocess/threaded server'.
> 
> The argument, once you've realised the above, is that of where do you
> store the context.  You need context -- it's either implicit in the call
> stack (threads), or explicit in the data structures
> (callback/event-driven).
> 
> Both camps have compelling stories on both sides of that argument (you
> have to start arguing microarchitectural details about caches, registers,
> and how the compiler interacts).  But the threads camp wins the "ease of
> implementation" argument in my books.

	I would readily agree about ease of use. I realised that the hard way a
few years ago when an initial event-driven model (on an embedded server)
got so way out of hand that it was much easier to write a few cpu
context switching routines and threadise the whole thing. Anyway, but if
that issue was to be set aside, should we simply accept Mark's assertion
that these so called fast servers 'cache the whole document tree and
only deal with network IO'? So when someone gives Zeus or other examples
of being 'fast by design', is there an element of truth in that. If yes,
what is it?

Cheers,
Nitin.

Mime
View raw message