Hello,
Thanks for the reply. Do you know how mod_ssl works?
It registers its function for a number of hooks from
the request preocessing sequence, but when these functions
are called, would this be only a library call inside the
same thread/process or is the request record passed to another
thread/process?
Best Regards,
Peter
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
