Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <3032cfcd0510301409x6ce41a31xccc3798653a9e13@mail.gmail.com>
References: <3032cfcd0510301409x6ce41a31xccc3798653a9e13@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <303FB30D-73FB-4EC0-99FD-2BF927831853@apache.org>
Content-Transfer-Encoding: 7bit
From: Brian Pane <brianp@apache.org>
Subject: Re: functions registered for hooks - do they run in same
 process/thread?
Date: Sun, 30 Oct 2005 14:40:08 -0800
To: dev@httpd.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