apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator
Date Sat, 21 Dec 2002 23:16:15 GMT

> >   What
> > you've done is said "The brigade may not live long enough", but you
> > haven't explained how that is the case.
> This, too, is something that we've discussed already.  Request
> cleanups can happen asynchronously relative to transmission of
> brigades created from the request.  Having a pool cleanup
> trigger the destruction of a brigade in another thread is
> dangerous.  The canonical solution is to migrate the data to
> a new brigade outside the pool before handing it off to another
> thread, which is fine as long as that doesn't create a need for
> another pool in the application (for the reasons noted above).

You are talking about an application that is built around pools.  If you
want an async MPM that uses a single thread to write data to the network
and multiple threads to generate the data, then your network I/O thread
will need to have a pool.  This pool will be very long lived (as long as
the process is alive).  You can allocate the brigade when the server
starts, and just re-use it forever.  You can have a pool of brigades that
are continuosly re-used, or you can create a sub-pool for each call into
your network write function.  But, moving brigade allocation outside of
pools isn't solving your problem and it is opening huge holes in the
abstraction that was created.

Screw it.  Buckets and bucket brigades are being moved into a project that
I no longer have any desire to work on.  My veto stands for as long as the
code is in an APR project.  The change is wrong and it is dangerous.  I
have explained why in detail.


View raw message