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 <trawick@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 <dev@httpd.apache.org>
On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick <trawick@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett <minfrin@sharp.fm> wrote:
>
>> On 26 Nov 2013, at 3:51 PM, Jeff Trawick <trawick@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/
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 <trawick@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 <dev@httpd.apache.org>
On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick <trawick@gmail.com> wrote:
> On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett <minfrin@sharp.fm> wrote:
>
>> On 26 Nov 2013, at 3:51 PM, Jeff Trawick <trawick@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/