functions registered for hooks - do they run in same process/thread?

[Peter Djalaliev <pe...@gmail.com>]

Hello,

I understand that a module registers its own functions for different hooks
in order to introduce its own functionality at different points of a request
handling. I also understand that the module can specify if it wants its
function to be executed first, in the middle or last, with relation to other
modules' functions registered for the same hook.

When these functions are actually called, do they execute in the same
process and thread (if threads are used) as the process/thread handling the
connection? For example, if the worker MPM module is used, a single thread
would handle a single connection. Would the mod_ssl code, for example,
execute within the thread for that connection?

I can be reached at peter.djalaliev@gmail.com

Best Regards,
Peter

Re: functions registered for hooks - do they run in same process/thread?

[Nick Kew <ni...@webthing.com>]

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

Re: functions registered for hooks - do they run in same process/thread?

[Brian Pane <br...@apache.org>]

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
- the logger invocation

In the future, there probably should be a third:

- processing in the handler phase that involves mainly waiting for
   network I/O (e.g., mod_proxy)

> That's going to break lots of things.  Like, any resource that's  
> used over
> more than one hook but that can't cross threads.  When was that major
> breakage discussed here?

What resources are you thinking off that can't cross threads?  I can't
find any examples of thread-local storage in the current set of core
modules.

Brian

Re: functions registered for hooks - do they run in same process/thread?

[Nick Kew <ni...@webthing.com>]

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.

That's going to break lots of things.  Like, any resource that's used over
more than one hook but that can't cross threads.  When was that major
breakage discussed here?

-- 
Nick Kew

Re: functions registered for hooks - do they run in same process/thread?

[Brian Pane <br...@apache.org>]

On Oct 30, 2005, at 2:09 PM, Peter Djalaliev wrote:

> Hello,
>
> I understand that a module registers its own functions for  
> different hooks
> in order to introduce its own functionality at different points of  
> a request
> handling. I also understand that the module can specify if it wants  
> its
> function to be executed first, in the middle or last, with relation  
> to other
> modules' functions registered for the same hook.
>
> When these functions are actually called, do they execute in the same
> process and thread (if threads are used) as the process/thread  
> handling the
> connection? For example, if the worker MPM module is used, a single  
> thread
> would handle a single connection. Would the mod_ssl code, for example,
> execute within the thread for that connection?

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.  (I think all of the MPMs in 2.0 happen to do all of the
processing of a request in the same thread, but that's more
an implementation detail than a design guarantee.)

What currently _is_ guaranteed, even in 2.3, is that at most
one thread at a time will process any given connection.  And,
as a corollary, at most one thread at a time will process any
given request.  (IMHO, this guarantee is one that we should
preserve in 2.4.)

Brian