You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2013/11/18 16:58:40 UTC
Does mod_perl/mod_??? need a hook called when a request/conn leaves
the original worker thread?
For the mod_perl crash with Event that I posted at the URL below, I would
suspect that there's some affinity with the original worker thread. Can
anyone in mod_perl land confirm?
http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
I'm also aware of a third-party diagnostic module that could use a hint,
and in general I wonder if anyone knows of specific interface requirements
that would need to be provided by a new hook for indicating when a
connection or request leaves the original thread or is handled by a new one.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 18, 2013, at 12:15 PM, Eric Covener <co...@gmail.com> wrote:
> On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick <tr...@gmail.com> wrote:
>> For the mod_perl crash with Event that I posted at the URL below, I would
>> suspect that there's some affinity with the original worker thread. Can
>> anyone in mod_perl land confirm?
>>
>> http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
>>
>> I'm also aware of a third-party diagnostic module that could use a hint, and
>> in general I wonder if anyone knows of specific interface requirements that
>> would need to be provided by a new hook for indicating when a connection or
>> request leaves the original thread or is handled by a new one.
>
> I can't see any need for more than request_rec on both ends.
>
mod_spdy uses a fake conn_rec, well, more like a sub-conn_rec
ala a subrequest, which is also sometimes called a slave
connection... I'm thinking that maybe having such an entity
here would be best, long term.
Re: Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 18, 2013, at 12:15 PM, Eric Covener <co...@gmail.com> wrote:
> On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick <tr...@gmail.com> wrote:
>> For the mod_perl crash with Event that I posted at the URL below, I would
>> suspect that there's some affinity with the original worker thread. Can
>> anyone in mod_perl land confirm?
>>
>> http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
>>
>> I'm also aware of a third-party diagnostic module that could use a hint, and
>> in general I wonder if anyone knows of specific interface requirements that
>> would need to be provided by a new hook for indicating when a connection or
>> request leaves the original thread or is handled by a new one.
>
> I can't see any need for more than request_rec on both ends.
>
mod_spdy uses a fake conn_rec, well, more like a sub-conn_rec
ala a subrequest, which is also sometimes called a slave
connection... I'm thinking that maybe having such an entity
here would be best, long term.
Fwd: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
Here's the current status...
The API isn't cast in stone yet. I'm only guessing that mod_perl cares
about this issue based on wild assumptions I'm making about the crash I
posted at
http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
If mod_perl doesn't have any sort of connections/request thread affinity
(i.e., is unaffected when a request or connection starts being handled on a
different native thread), that would be great to know too, since that
simplifies the discussion.
---------- Forwarded message ----------
From: Jeff Trawick <tr...@gmail.com>
Date: Tue, Nov 26, 2013 at 3:17 PM
Subject: Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
To: Apache HTTP Server Development List <de...@httpd.apache.org>
On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
>> On 26 Nov 2013, at 3:51 PM, Jeff Trawick <tr...@gmail.com> wrote:
>>
>> > As it turns out (or, why didn't I refresh my understanding before), the
>> MPM only knows about the conn_rec.
>> >
>> > * It could do extra work to learn about the request in order to pass
>> the request to the new hook.
>> > * It could avoid that extra work for configurations that don't have a
>> module that implements the hook.
>> >
>> > I'm leaning towards not having the MPM bother with any of that. Such
>> magic is well within the scope of a module that cares about detaching from
>> the thread anyway.
>>
>> It would be nice if there was a clean and consistent way for
>> c->output_filters to become r->output_filters, and when the request is
>> cleaned up for the c->output_filters to be reverted back to what it was
>> before.
>>
>> This way content and resource filters could take advantage of write
>> completion in future.
>>
>
> Interesting... I don't know exactly what "clean ... way" will mean in
> this context, but I can look at early-request-hook+request-pool-cleanup
> processing to let the MPM track the current r for a connection.
>
>
>>
>> Regards,
>> Graham
>> --
>>
>>
>
>
Here's a first draft for suspend/resume hooks:
http://people.apache.org/~trawick/suspend_resume_hooks_r1.txt
This maintains r inside the event MPM connection state.
>From a module that tries to log r->the_request when the connection is
suspended or resumed:
[pid 31968:139866574595840] suspend, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866566203136] resume, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866566203136] suspend, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866557810432] resume, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866557810432] suspend, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866549417728] resume, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
...
[pid 31968:139866725664512] suspend, r 0
(For detecting the end of the request or connection, the module needs to
use a cleanup on the appropriate pool as always.)
Todos (that I know of so far :) ):
1. call the new hooks from places other than process_socket()
2. consider passing a coarse, non-MPM-specific, representation of the state
on the hook calls
--
Born in Roswell... married an alien...
http://emptyhammock.com/
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Nov 30, 2013 at 10:03 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 3:17 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick <tr...@gmail.com> wrote:
>>
>>> On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett <mi...@sharp.fm>wrote:
>>>
>>>> On 26 Nov 2013, at 3:51 PM, Jeff Trawick <tr...@gmail.com> wrote:
>>>>
>>>> > As it turns out (or, why didn't I refresh my understanding before),
>>>> the MPM only knows about the conn_rec.
>>>> >
>>>> > * It could do extra work to learn about the request in order to pass
>>>> the request to the new hook.
>>>> > * It could avoid that extra work for configurations that don't have a
>>>> module that implements the hook.
>>>> >
>>>> > I'm leaning towards not having the MPM bother with any of that. Such
>>>> magic is well within the scope of a module that cares about detaching from
>>>> the thread anyway.
>>>>
>>>> It would be nice if there was a clean and consistent way for
>>>> c->output_filters to become r->output_filters, and when the request is
>>>> cleaned up for the c->output_filters to be reverted back to what it was
>>>> before.
>>>>
>>>> This way content and resource filters could take advantage of write
>>>> completion in future.
>>>>
>>>
>>> Interesting... I don't know exactly what "clean ... way" will mean in
>>> this context, but I can look at early-request-hook+request-pool-cleanup
>>> processing to let the MPM track the current r for a connection.
>>>
>>>
>>>>
>>>> Regards,
>>>> Graham
>>>> --
>>>>
>>>>
>>>
>>>
>> Here's a first draft for suspend/resume hooks:
>>
>> http://people.apache.org/~trawick/suspend_resume_hooks_r1.txt
>>
>> This maintains r inside the event MPM connection state.
>>
>> From a module that tries to log r->the_request when the connection is
>> suspended or resumed:
>>
>> [pid 31968:139866574595840] suspend, r 7f3530002970 GET
>> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
>> [pid 31968:139866566203136] resume, r 7f3530002970 GET
>> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
>> [pid 31968:139866566203136] suspend, r 7f3530002970 GET
>> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
>> [pid 31968:139866557810432] resume, r 7f3530002970 GET
>> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
>> [pid 31968:139866557810432] suspend, r 7f3530002970 GET
>> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
>> [pid 31968:139866549417728] resume, r 7f3530002970 GET
>> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
>> ...
>> [pid 31968:139866725664512] suspend, r 0
>>
>> (For detecting the end of the request or connection, the module needs to
>> use a cleanup on the appropriate pool as always.)
>>
>> Todos (that I know of so far :) ):
>>
>> 1. call the new hooks from places other than process_socket()
>>
>
> AFAICT, the other place where conn-specific* non-MPM code can run is in
> pool cleanups, so resume may have to be called in a "pre-cleanup", if the
> conn is currently suspended.
>
> *There are special callbacks handled by event[/eventopt] but they're not
> associated with the client connection conn_rec so they are not the target
> of the suspend/resume hooks.
>
>
>> 2. consider passing a coarse, non-MPM-specific, representation of the
>> state on the hook calls
>>
>
> I didn't realize that the conn_rec already has a very fine-grained
> representation of the state. This state info is sufficient and, as it is
> already part of the API, there's no concern at this point in creating a
> coarse representation that is easier for multiple MPMs to maintain without
> breaking the API when the MPM implementation changes.
>
Implemented for Event in r1546759; I'll implement for eventopt before
long; it would be great if Event-savvy folks would take a look ;)
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Nov 26, 2013 at 3:17 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick <tr...@gmail.com> wrote:
>
>> On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett <mi...@sharp.fm> wrote:
>>
>>> On 26 Nov 2013, at 3:51 PM, Jeff Trawick <tr...@gmail.com> wrote:
>>>
>>> > As it turns out (or, why didn't I refresh my understanding before),
>>> the MPM only knows about the conn_rec.
>>> >
>>> > * It could do extra work to learn about the request in order to pass
>>> the request to the new hook.
>>> > * It could avoid that extra work for configurations that don't have a
>>> module that implements the hook.
>>> >
>>> > I'm leaning towards not having the MPM bother with any of that. Such
>>> magic is well within the scope of a module that cares about detaching from
>>> the thread anyway.
>>>
>>> It would be nice if there was a clean and consistent way for
>>> c->output_filters to become r->output_filters, and when the request is
>>> cleaned up for the c->output_filters to be reverted back to what it was
>>> before.
>>>
>>> This way content and resource filters could take advantage of write
>>> completion in future.
>>>
>>
>> Interesting... I don't know exactly what "clean ... way" will mean in
>> this context, but I can look at early-request-hook+request-pool-cleanup
>> processing to let the MPM track the current r for a connection.
>>
>>
>>>
>>> Regards,
>>> Graham
>>> --
>>>
>>>
>>
>>
> Here's a first draft for suspend/resume hooks:
>
> http://people.apache.org/~trawick/suspend_resume_hooks_r1.txt
>
> This maintains r inside the event MPM connection state.
>
> From a module that tries to log r->the_request when the connection is
> suspended or resumed:
>
> [pid 31968:139866574595840] suspend, r 7f3530002970 GET
> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
> [pid 31968:139866566203136] resume, r 7f3530002970 GET
> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
> [pid 31968:139866566203136] suspend, r 7f3530002970 GET
> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
> [pid 31968:139866557810432] resume, r 7f3530002970 GET
> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
> [pid 31968:139866557810432] suspend, r 7f3530002970 GET
> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
> [pid 31968:139866549417728] resume, r 7f3530002970 GET
> /ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
> ...
> [pid 31968:139866725664512] suspend, r 0
>
> (For detecting the end of the request or connection, the module needs to
> use a cleanup on the appropriate pool as always.)
>
> Todos (that I know of so far :) ):
>
> 1. call the new hooks from places other than process_socket()
>
AFAICT, the other place where conn-specific* non-MPM code can run is in
pool cleanups, so resume may have to be called in a "pre-cleanup", if the
conn is currently suspended.
*There are special callbacks handled by event[/eventopt] but they're not
associated with the client connection conn_rec so they are not the target
of the suspend/resume hooks.
> 2. consider passing a coarse, non-MPM-specific, representation of the
> state on the hook calls
>
I didn't realize that the conn_rec already has a very fine-grained
representation of the state. This state info is sufficient and, as it is
already part of the API, there's no concern at this point in creating a
coarse representation that is easier for multiple MPMs to maintain without
breaking the API when the MPM implementation changes.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick <tr...@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
>> On 26 Nov 2013, at 3:51 PM, Jeff Trawick <tr...@gmail.com> wrote:
>>
>> > As it turns out (or, why didn't I refresh my understanding before), the
>> MPM only knows about the conn_rec.
>> >
>> > * It could do extra work to learn about the request in order to pass
>> the request to the new hook.
>> > * It could avoid that extra work for configurations that don't have a
>> module that implements the hook.
>> >
>> > I'm leaning towards not having the MPM bother with any of that. Such
>> magic is well within the scope of a module that cares about detaching from
>> the thread anyway.
>>
>> It would be nice if there was a clean and consistent way for
>> c->output_filters to become r->output_filters, and when the request is
>> cleaned up for the c->output_filters to be reverted back to what it was
>> before.
>>
>> This way content and resource filters could take advantage of write
>> completion in future.
>>
>
> Interesting... I don't know exactly what "clean ... way" will mean in
> this context, but I can look at early-request-hook+request-pool-cleanup
> processing to let the MPM track the current r for a connection.
>
>
>>
>> Regards,
>> Graham
>> --
>>
>>
>
>
Here's a first draft for suspend/resume hooks:
http://people.apache.org/~trawick/suspend_resume_hooks_r1.txt
This maintains r inside the event MPM connection state.
>From a module that tries to log r->the_request when the connection is
suspended or resumed:
[pid 31968:139866574595840] suspend, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866566203136] resume, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866566203136] suspend, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866557810432] resume, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866557810432] suspend, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
[pid 31968:139866549417728] resume, r 7f3530002970 GET
/ubuntu-12.04.3-desktop-i386.iso HTTP/1.1
...
[pid 31968:139866725664512] suspend, r 0
(For detecting the end of the request or connection, the module needs to
use a cleanup on the appropriate pool as always.)
Todos (that I know of so far :) ):
1. call the new hooks from places other than process_socket()
2. consider passing a coarse, non-MPM-specific, representation of the state
on the hook calls
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 26 Nov 2013, at 3:51 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
> > As it turns out (or, why didn't I refresh my understanding before), the
> MPM only knows about the conn_rec.
> >
> > * It could do extra work to learn about the request in order to pass the
> request to the new hook.
> > * It could avoid that extra work for configurations that don't have a
> module that implements the hook.
> >
> > I'm leaning towards not having the MPM bother with any of that. Such
> magic is well within the scope of a module that cares about detaching from
> the thread anyway.
>
> It would be nice if there was a clean and consistent way for
> c->output_filters to become r->output_filters, and when the request is
> cleaned up for the c->output_filters to be reverted back to what it was
> before.
>
> This way content and resource filters could take advantage of write
> completion in future.
>
Interesting... I don't know exactly what "clean ... way" will mean in this
context, but I can look at early-request-hook+request-pool-cleanup
processing to let the MPM track the current r for a connection.
>
> Regards,
> Graham
> --
>
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
Posted by Graham Leggett <mi...@sharp.fm>.
On 26 Nov 2013, at 3:51 PM, Jeff Trawick <tr...@gmail.com> wrote:
> As it turns out (or, why didn't I refresh my understanding before), the MPM only knows about the conn_rec.
>
> * It could do extra work to learn about the request in order to pass the request to the new hook.
> * It could avoid that extra work for configurations that don't have a module that implements the hook.
>
> I'm leaning towards not having the MPM bother with any of that. Such magic is well within the scope of a module that cares about detaching from the thread anyway.
It would be nice if there was a clean and consistent way for c->output_filters to become r->output_filters, and when the request is cleaned up for the c->output_filters to be reverted back to what it was before.
This way content and resource filters could take advantage of write completion in future.
Regards,
Graham
--
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Nov 18, 2013 at 12:15 PM, Eric Covener <co...@gmail.com> wrote:
> On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick <tr...@gmail.com> wrote:
> > For the mod_perl crash with Event that I posted at the URL below, I would
> > suspect that there's some affinity with the original worker thread. Can
> > anyone in mod_perl land confirm?
> >
> >
> http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
> >
> > I'm also aware of a third-party diagnostic module that could use a hint,
> and
> > in general I wonder if anyone knows of specific interface requirements
> that
> > would need to be provided by a new hook for indicating when a connection
> or
> > request leaves the original thread or is handled by a new one.
>
> I can't see any need for more than request_rec on both ends.
>
As it turns out (or, why didn't I refresh my understanding before), the MPM
only knows about the conn_rec.
* It could do extra work to learn about the request in order to pass the
request to the new hook.
* It could avoid that extra work for configurations that don't have a
module that implements the hook.
I'm leaning towards not having the MPM bother with any of that. Such magic
is well within the scope of a module that cares about detaching from the
thread anyway.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Eric Covener <co...@gmail.com>.
On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick <tr...@gmail.com> wrote:
> For the mod_perl crash with Event that I posted at the URL below, I would
> suspect that there's some affinity with the original worker thread. Can
> anyone in mod_perl land confirm?
>
> http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
>
> I'm also aware of a third-party diagnostic module that could use a hint, and
> in general I wonder if anyone knows of specific interface requirements that
> would need to be provided by a new hook for indicating when a connection or
> request leaves the original thread or is handled by a new one.
I can't see any need for more than request_rec on both ends.
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
Ouch, I meant to sent this to dev@perl instead of dev@apr...
On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick <tr...@gmail.com> wrote:
> For the mod_perl crash with Event that I posted at the URL below, I would
> suspect that there's some affinity with the original worker thread. Can
> anyone in mod_perl land confirm?
>
>
> http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
>
> I'm also aware of a third-party diagnostic module that could use a hint,
> and in general I wonder if anyone knows of specific interface requirements
> that would need to be provided by a new hook for indicating when a
> connection or request leaves the original thread or is handled by a new one.
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Eric Covener <co...@gmail.com>.
On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick <tr...@gmail.com> wrote:
> For the mod_perl crash with Event that I posted at the URL below, I would
> suspect that there's some affinity with the original worker thread. Can
> anyone in mod_perl land confirm?
>
> http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
>
> I'm also aware of a third-party diagnostic module that could use a hint, and
> in general I wonder if anyone knows of specific interface requirements that
> would need to be provided by a new hook for indicating when a connection or
> request leaves the original thread or is handled by a new one.
I can't see any need for more than request_rec on both ends.
Re: Does mod_perl/mod_??? need a hook called when a request/conn
leaves the original worker thread?
Posted by Jeff Trawick <tr...@gmail.com>.
Ouch, I meant to sent this to dev@perl instead of dev@apr...
On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick <tr...@gmail.com> wrote:
> For the mod_perl crash with Event that I posted at the URL below, I would
> suspect that there's some affinity with the original worker thread. Can
> anyone in mod_perl land confirm?
>
>
> http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E
>
> I'm also aware of a third-party diagnostic module that could use a hint,
> and in general I wonder if anyone knows of specific interface requirements
> that would need to be provided by a new hook for indicating when a
> connection or request leaves the original thread or is handled by a new one.
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>
--
Born in Roswell... married an alien...
http://emptyhammock.com/