httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Another async I/O proposal [was Re: request for comments: multiple-connections-per-thread MPM design]
Date Tue, 26 Nov 2002 04:59:17 GMT
On Mon, Nov 25, 2002 at 08:10:12AM -0800, Brian Pane wrote:
> On Mon, 2002-11-25 at 00:02, Manoj Kasichainula wrote:
> > while (event = get_next_event())
> >    add more spare threads if needed
> >    event_processor = lookup_event_processor(event)
> >    ticket = event_processor(event)
> >    if (ticket) submit_ticket(ticket)
> >    exit loop (and thus end thread) if not needed
> > 
> > The event_processor can take as long as it wants, since there are other
> > threads who can wait for the next event.
> Where is the locking done?  Is the lock just around the
> get_next_event() call?

Yeah, I imagined the locking would be implicit in there. Different event
mechanisms on various OSes could require different locking schemes, so
if locking is needed, it should be hidden there.

> Once the httpd_request_processor() has created a new ticket for
> the write, how does the submit_ticket() get the socket added into
> the pollset?  If it's possible for another request to be in the
> middle of a poll call at the same time, does submit_ticket()
> interrupt the poll in order to add the new descriptor?

This is a problem I missed somehow. I mentioned it in the other branch
of the thread.

> - Flow control will be difficult.  Here's a tricky scenario I
>   just thought of:  The server is configured to run 10 threads.
>   Most of the time, it only needs a couple of them, because it's
>   serving mostly static content and and occasional PHP request.
>   Suddenly, it gets a flood of requests for PHP pages.  The first
>   ten of these quickly take over the ten available threads.
>   PHP doesn't know how to work in an event-driven world, each
>   of these requests holds onto its thread for a long time.  When
>   one of them finally completes, it produces some content to be
>   written.  But the writes may be starved, because the first
>   thread that finishes its PHP request and goes back into the
>   select loop might find another incoming request and read it
>   before doing any writes.  And if that new request is another
>   long-running PHP request, it could be a while before we finally
>   get around to doing the write.

Hmm, yeah, this is a concern. One answer is to set a very high
MaxThreadLimit, but then you can't control how many PHP threads you
have. Another answer is to reserve some threads for I/O, which your
design does.

>   It's possible to partly work around this by implementing
>   get_next_event() so that it completes all pending, unblocked
>   writes before returning.  But more generally, we'll need some
>   solution to keep long-running, non-event-based requests from
>   taking over all the server threads.  (This is true of my design
>   as well.)

Actually, in your design, since you have seperate threads for I/O, I
don't see why it would suffer.

View raw message