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. Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
