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.
