Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Errors-To: <wrowe@rowe-clan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <new-httpd@apache.org>
Subject: RE: Implementing split() on pipe buckets?
Date: Sat, 11 Nov 2000 22:53:02 -0600
Message-ID: <002401c04c64$704eb1e0$92c0b0d0@roweclan.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <Pine.LNX.4.21.0011112021300.24700-100000@koj.rkbloom.net>

> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Saturday, November 11, 2000 10:26 PM
> 
> > I agree with you that duplicate can't work on a pipe or socket, but I really
> > disagree here.  We discussed at the filtering meeting that there are several
> > key operations that must -always- be implemented, and -always- work.  These
> > would be create, destroy, read and split.  Anything else is negotiable.
> 
> No, at the filter meeting, the only functions that we said would always
> work are create and read.  Everything is negotiable.  In this case, a
> split on a pipe or socket just can't be done cleanly.  I explained why in
> another message just now.

Destroy always works (it simply may be a noop if it is immortal, or may be
deferred if the refcount isn't 0.)  

I'm not going to argue split either way, since the pipe/socket cases wern't 
fully considered at that meeting. 

The cases we are discussing are all fifo problems.  Can't we have a common
wrapper that handles (with the extra error conditions) any fifo bucket, outside
of the explicit and atomic calls (split, duplicate) that offer predictable fifo
behavior for filters that don't care to work around these issues themselves?
e.g. ap_bucket_split_any, ap_bucket_duplicate_any, etc.  They can carry their
documented shortcomings, and the author who uses them does so at a cost?

These aren't implemented bucket-by-bucket, so won't carry the costs to the
bucket author.  They are predictable, so the filter author must be prepared to
handle additional error results (potential read+split or read+duplicate errors.)

It's granular, saves code, and doesn't polute buckets.  Is that a good comprimize?