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.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. > 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/
