On Sunday 30 October 2005 23:07, Brian Pane wrote: > On Oct 30, 2005, at 2:46 PM, Nick Kew wrote: > > On Sunday 30 October 2005 22:40, Brian Pane wrote: > >> Strictly speaking, there's no guarantee that a request will be > >> processed by one and only one thread. It's possible for a > >> threaded MPM to hand off a request from one thread to another. > >> For example, the version of the Event MPM in 2.3 can run the > >> logger hook for a request in a different thread than the handler > >> hook. > > > > Really? I thought the async activity was the I/O, not the request > > processing. > > There are two aspects of request processing that can happen > asynchronously: > > - anything the modules add to the connection-level output filters
Hmmm. That's OK as far as I'm concerned (I think), but should at least be properly documented. Crucially, it's outside the Request. > - the logger invocation Ouch! That's a request processing phase. It's imposing new constraints on what can be kept on the request config, which worries me a lot. For example, might it break (at least some drivers for) DBD, if a handle crosses threads within a request? Or a script interpreter from a scripting module? > What resources are you thinking off that can't cross threads? Frankly, I don't know. Presumably there's no such thing as a threading implementation where threads have their own private address space, or every pointer - eg the request pool -would fall about in a heap in this model? At the very least, this needs some serious documentation. -- Nick Kew
