Re: Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
On Tue, Nov 26, 2013 at 3:17 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick traw...@gmail.com wrote: On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett minf...@sharp.fm wrote: On 26 Nov 2013, at 3:51 PM, Jeff Trawick traw...@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?
On Sat, Nov 30, 2013 at 10:03 AM, Jeff Trawick traw...@gmail.com wrote: On Tue, Nov 26, 2013 at 3:17 PM, Jeff Trawick traw...@gmail.com wrote: On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick traw...@gmail.com wrote: On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett minf...@sharp.fmwrote: On 26 Nov 2013, at 3:51 PM, Jeff Trawick traw...@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?
On Mon, Nov 18, 2013 at 12:15 PM, Eric Covener cove...@gmail.com wrote: On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick traw...@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?
On 26 Nov 2013, at 3:51 PM, Jeff Trawick traw...@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?
On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett minf...@sharp.fm wrote: On 26 Nov 2013, at 3:51 PM, Jeff Trawick traw...@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?
On Tue, Nov 26, 2013 at 9:01 AM, Jeff Trawick traw...@gmail.com wrote: On Tue, Nov 26, 2013 at 8:55 AM, Graham Leggett minf...@sharp.fm wrote: On 26 Nov 2013, at 3:51 PM, Jeff Trawick traw...@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/
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?
On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick traw...@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?
On Nov 18, 2013, at 12:15 PM, Eric Covener cove...@gmail.com wrote: On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick traw...@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?
Ouch, I meant to sent this to dev@perl instead of dev@apr... On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick traw...@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/
