httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: Event MPM
Date Mon, 25 Oct 2004 18:25:07 GMT
Greg Ames wrote:
>> First is a patch to APR that provides an extension to apr_pollset that 
>> optionally make some parts of it threadsafe.  This patch has been 
>> submitted to APR before, and hopefully it will get accepted there soon.
> I need to catch up here.  quick questions: will this event MPM work with 
> conventional poll (i.e. no epoll or kqueue)?  Can it handle a worker 
> thread adding directly to the pollset?

The patch to APR adds a new 'APR_POLLSET_THREADSAFE' flag for 

This only works for the EPoll and KQueue backends.  This allows a worker 
thread to _add() or _remove() directly, without having to touch the 
thread in _poll().

It could be implemented for plain Poll by having the pollset contain an 
internal pipe.  This Pipe could be pushed by an _add() or _remove() and 
force the _poll() thread to wake up. The thread in _poll() could then 
add or remove any sockets from it's set, and then start the _poll() 

This is how your original patch did it, but we could push it down to 
APR.  I don't think in the end it will yield good performance with this 

My personal view is that most platforms will have either EPoll() or 
KQueue() Support.  I guess its only an issue for people running 2.2./2.4 
Linux, since KQueue has been in *BSD for a long time.  As time passes, I 
believe that implementing it for plain poll() will be come less important.

Other platforms like Solaris have better poll() replacements that we 
should add to apr_pollset_*.

>> I have made the MPM a single process with multiple threads  
> interesting!  but then per process limits (fd's esp. for sockets, 
> virtual memory) could put a ceiling on how high this can scale.  Plus if 
> a buggy module seg faults, it's a lot more disruptive when there's only 
> one worker process.

We don't have buggy modules :-)

Isn't the per-process FD limit only really a problem for platforms like 
older Solaris?  I thought that on Linux/BSD it is quite high by default now.

>>    It currently does not spawn new threads on demand, but I plan to 
>> add this soon.  By making it run as a single process, I was able to 
>> completely remove the accept() locking.  This also greatly simplifies 
>> the Listener Thread's poll()`ing of the sockets.
> understood, but see above.  My vote is to keep it multiprocess capable 
> and perhaps allow a single process ./configure option.

I am not completely adverse to putting multi-processes back in, I mostly 
wanted to get a working patch out there for review.

The current logic used in Worker is flawed for poll`ing of Listening 
sockets.  I just ripped all of it out, and ended up with a much simpler 
MPM that avoids extra locking.

>> The Worker Threads work much like the 'Worker' MPM, but when a 
>> connection is ready for a Keep Alive, they will push the client back 
>> to the Listener/Event Thread.  This thread does not need to be woken 
>> up like in Greg Ames' patch.  This is because of the enhancement to 
>> apr_pollset that enables other threads to _add() or _remove() while 
>> the main thread is inside a _poll().
> even with plain ol' vanilla poll() ?

Nope. Its just not easily to implement and support plain old vanilla 
poll().  You cannot just add an FD to its array of sockets from other 
threads.  The poll() will also not see any changes in its list until you 
wake it up, and start the poll() again.

This is not impossible to implement, but its going to have a huge number 
of context switches for what should be a very common operation.

>> The place where the Event MPM should shine is with the more common 
>> case of relatively high-latency Internet clients.  The Event MPM isn't 
>> super powerful on the KeepAlive-over-LAN case because it forces a 
>> context switch to process the client again when it is does another 
>> request as part of a KeepAlive.
> I heard of an application where many clients send a heartbeat to a 
> server over http every few seconds.  That would benefit greatly by using 
> keepalives and some form of event MPM, even over a LAN.


Another place the event MPM would rock is on an FTP server. (see mod_ftpd).

Yet Another place is an IMAPv4 server written as an Apache Module. (This 
is on my ~/TODO list)

Thanks for the Feedback!

-Paul Querna

View raw message