httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [PATCH] tracking active request phase
Date Mon, 28 Feb 2005 20:59:22 GMT
At 09:17 AM 2/28/2005, Jeff Trawick wrote:
>On Mon, 28 Feb 2005 08:39:06 -0600, William A. Rowe, Jr.
><wrowe@rowe-clan.net> wrote:
>> Wow :)  That would be extraordinarily useful.  Any hope the scheme
>> would be extensible, so a module such as cgi or rewrite could show
>> more specific Phases?
>
>I'm leaning towards having completely accurate info maintained by the
>core, and arbitrary modules would need to use a separate mechanism to
>provide more info.  I see enough implementation problems in non-core
>modules to be skeptical that such modules could be trusted to safely
>interoperate with core with the maintenance of a single indication of
>state.

What if the API enforced that we restored our state whenever the module
is back in our control.  String handling would be cpu-intensive, but
if the various dispatch modules simply reset the const string to the
same value pointer, this wouldn't be very intensive at all.

I agree in principal, while running within the core, it should be our
choice of state.  Once it enters the users handler or filter code 
(and they have not passed the brigade up the stack yet) it would be
very useful to see their consideration of the current phase.

e.g.

core...

  phase="handler"
  run_request()
    ... {module resets phase}
    pass_brigade()
      oldphase = phase
      phase="filter"
      ... {module's filter mucks with phase}
        brigade_next()
        oldphase = phase
        phase="filter"
        phase = oldphase
        ...
      ...
      phase = oldphase
    ...
  phase="Done"

Forgive the sloppy style, but you get the concept I have.

Bill 


Mime
View raw message