[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: functions registered for hooks - do they run in same process/thread?
From:       Peter Djalaliev <peter.djalaliev () gmail ! com>
Date:       2005-10-31 14:15:12
Message-ID: 3032cfcd0510310615u42e43229g551fbb98c78f7543 () mail ! gmail ! com
[Download RAW message or body]

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 h=
ooks 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

[Attachment #3 (text/html)]

<pre style="margin: 0em;">Hello,<br><br>Thanks for the reply.  Do you know how \
mod_ssl works?  <br>It registers its function for a number of hooks from <br>the \
request preocessing sequence, but when these functions <br>are called, would this be \
only a library call inside the  <br>same thread/process or is the request record \
passed to another <br>thread/process?<br><br>Best Regards,<br>Peter<br><br>On Oct 30, \
2005, at 2:09 PM, Peter Djalaliev wrote:<br>&gt; Hello,<br><tt>&gt;<br>&gt; I \
understand that a module registers its own functions for   </tt><tt>&gt; different \
hooks </tt><tt>in order to introduce its own<br>&gt; functionality at different \
points of</tt><tt> a request </tt><tt>handling.<br>&gt; I also understand that the \
module can specify if it wants<br> &gt; </tt><tt>its </tt><tt>function to be executed \
first, in the middle or last,<br>&gt; with relation </tt>to other modules' functions \
registered for <br>&gt; the same hook.<br><br>&gt; When these functions are actually \
called, do they execute  <br>&gt; in the same<tt> process and thread (if threads are \
used) as <br>&gt; the process/thread </tt><tt>handling the </tt><tt>connection? For \
example,<br>&gt; if the worker MPM module is used, a single </tt>thread would  \
<br>&gt; handle a single connection. Would the mod_ssl code, for <br>&gt; example, \
execute within the thread for that connection?<br></pre><pre style="margin: \
0em;"><br>Strictly speaking, there's no guarantee that a request will be \
<br>processed by one and only one thread.  It's possible for a<br>threaded MPM to \
hand off a request from one thread to another.<br>For example, the version of the \
Event MPM in 2.3 can run the<br>logger hook for a request in a different thread than \
the handler <br>hook.  (I think all of the MPMs in 2.0 happen to do all of \
the<br>processing of a request in the same thread, but that's more<br>an \
implementation detail than a design guarantee.)<br><br>What currently _is_ \
guaranteed, even in  2.3, is that at most<br>one thread at a time will process any \
given connection.  And,<br>as a corollary, at most one thread at a time will process \
any<br>given request.  (IMHO, this guarantee is one that we should<br>preserve in  \
2.4.)<br><br>Brian<br><br></pre>



[prev in list] [next in list] [prev in thread] [next in thread]