httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Events, Destruction and Locking
Date Tue, 07 Jul 2009 11:34:37 GMT
Paul Querna wrote:

> Can't sleep, so finally writing this email I've been meaning to write
> for about 7 months now :D
> One of the challenges in the Simple MPM, and to a smaller degree in
> the Event MPM, is how to manage memory allocation, destruction, and
> thread safety.
> A 'simple' example:
>  - 1) Thread A: Client Connection Created
>    -  2) Thread A: Timer Event Added for 10 seconds in the future to
> detect  IO timeout,
>  - 3) Thread B: Client Socket closes in 9.99 seconds.
>  - 4) Thread C: Timer Event for IO timeout is triggered after 10 seconds
> The simple answer is placing a Mutex around the connection object.
> Any operation which two threads are working on the connection, locks
> this Mutex.

As you've said, locks create many problems, the most fatal of which is
that locks potentially block the event loop. Ideally if a try_lock
fails, the event should reschedule itself to try again at some point in
the near future, but that relies on people bothering to write this
logic, and I suspect many won't.

A pragmatic approach might be to handle a request completely within a
single event loop running in a single thread. In this case the timer
event for IO timeout is in the same thread as the socket close event.

At this point you just need to make sure that your pool cleanups are
handled correctly. So if a timeout runs, all the timeout does is
apr_destroy_pool(r->pool), and that's it. It is up to the pool cleanup
to make sure that all events (such as the event that calls connection
close) are cleanly deregistered so that they won't get called in future.

We may offer a mechanism (such as a watchdog) that allows a request to
kick off code in another thread, but a prerequisite for that is that the
pool cleanup will have to be created to make sure that other thread is
terminated cleanly, or the request is cleanly removed from that other
thread's event loop.

> I think it is possible to write a complete server that deals with all
> these intricacies and gets everything just 'right', but as soon as you
> introduce 3rd party module writers, no matter how 'smart' we are, our
> castle of event goodness will crumble.

You've hit the nail on the head as to why the prefork and worker models
are still relevant - they are very forgiving of "irresponsible
behaviour" by modules.


View raw message