httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: select vs. threads vs. fork
Date Mon, 19 Apr 1999 22:19:37 GMT

On Mon, 19 Apr 1999, Nitin Sonawane wrote:

> The second issue I dont understand is 'unnecessary context switches'.

The goal is to maximize the use of every timeslice the kernel hands your
thread/task/process/lwp/whatever.  Kernel context switches tend to be more
heavyweight than userland switches (which are about as expensive as a
function call).

> Isnt it the case that the kernel is incessantly servicing peripheral
> interrupts. If so wouldnt context switches be almost unavoidable? 

In some sense yeah, but you're talking about a different context.  Also,
high speed networking is polled rather than interrupt driven -- because
it's cheaper to poll than it is to take interrupts. 

> Speaking of mit-pthreads, barring some overhead wouldnt such a server
> internally behave in the same manner as a select/poll based system. If
> yes, then we should be able to compile apache-apr with mit-pthreads and
> see how that performs in terms of sheer throughput.

Yes.  (Which is exactly what gets said in this thread every time it arises

Some of this is in the apache-2.0/docs archive as well.  You should find
Sun's document describing their hybrid user/kernel pthreads
implementation.  You can also look at NSPR's hybrid user/kernel
implementation that lives on IRIX -- and which has the potential to live
on any kernel pthreads implementation (i.e. linux).

> 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

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.


View raw message