httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: [VOTE] ap_r* model.
Date Fri, 02 Mar 2001 21:56:32 GMT
On Fri, 2 Mar 2001, Bill Stoddard wrote:

> > > I think I remember gstein writing...
> > >
> > > > happen", but can only happen by a deliberate action of a module author.
> They
> > > > have to take special measures to get themselves in front of OLD_WRITE.
> We
> > > > don't have to take precautions against deliberate troublemakers; there
> are
> > > > too many other ways that a module author can screw things up.
> > >
> > > The problem isn't me as a module author, it is the other guy.  My module
> > > may be fine, but what if there is another module that isn't.
> >
> > Here's the upshot.
> >
> > OLD_WRITE filter can be blown away not paying attention to filter ordering.
> >
> > r->bb can be blown away by anyone not paying attention to the request's own
> brigade.
> >
> > Which of these is harder to debug ?!?  Harder to document ?!?  That's the
> key!
> >
> > [We aren't talking about buckets here guys... the -brigade- is that stream
> that
> > is sent down the filter stack.  I have yet to be convinced we need more than
> one
> > per request.  As FirstBill and rbb point out, you just keep adding to it.]
> >
> > I see ordering problems as the hardest headache to debug.  r->bb misordering
> is
> > fairly straightforward - if you start misordering, the module _author_
> messed up.
> > If you have a filtering problem, the user will have some impact on filter
> ordering.
> > That means they can create a problem.  If it's a choice between the module
> author
> > and the end user creating bugs, I'll take the author's bugs any day.
> >
>
> I'll pose the questions that are most important to me...  I ship a binary only
> copy of a server based on Apache 2.0.  My customer may add their own or third
> party modules to the server.  What do they  (and the third party module
> authors) need to know to not screw up?  I voted for r->bb initially based
> largely on design purity and philosophy but I am still listening to the
> arguments and may switch based on Greg's comments.  Which is the most fool
> proof in the common cases?  What are the common cases (filter to add a custom
> header? filters to do transcoding?, content generators?).

Here's the thing.  If you are in a handler, as long as r->bb is used, then
there is no chance of getting data out of order, and the performance is
good.  If you are in a function called from a handler, there are very few
options.  1)  A brigade is passed in (the handler should pass r->bb), 2)
no brigade is passed in.  In case 2, the function should use ap_r or
r->bb.  But, case 2 should never happen.  If it does happen, then the
function really isn't all that useful, because it can only EVER be called
from a handler.  It also has the disadvantage that the following will
cause ordering problems:


	foo = ap_create_brigade(p);
	ap_insert_bucket(foo, ap_make_bucket_heap("FOO BAR"));
	subsystem(r);    /* This sends BAZ to the next filter */
	ap_pass_brigade(foo);

In this case, using OLD_WRITE, you will get:

	BAZ FOO BAR

With r->bb, just change foo to r->bb, and assume subsystem is written
intelligently, and you get:

	FOO BAR BAZ

Which, is what I would expect.

By written intelligently, I would expect that susbsystem either uses r->bb
or ap_r* to write to the network.  To make OLD_WRITE work with the above
code, you need to call ap_pass_brigade before calling subsystem.

To make the solution even cleaner, change subsystem the subsystem call to:

	subsystem(r->bb);

This will actually work with both models, and we remove any possibility of
having data out of order.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------




Mime
View raw message