[ I'm still trying to catch up on several weeks of email... just a quick note on something here... ]
On Mon, Dec 31, 2001 at 10:02:41AM -0800, Ryan Bloom wrote: > On Monday 31 December 2001 02:40 am, Justin Erenkrantz wrote: >... > > I think the best strategy would be to introduce a new input filter > > mode (call it PEEK and rename the current PEEK mode to EATCRLF) that > > I would recommend not re-using the PEEK mode, because that will > cause confusion to people who have written input filters already. Regardless, the existing PEEK ought to be renamed EATCRLF. Or even tossed entirely somehow. >... > > 5. Run through all buckets in the brigade and read/copy into > > the caller's buffer. (What happened to zero-copy?) > > We don't do zero-copy on input. The real benefit to zero-copy > is on output, because the data tends to be larger. There *should* be a benefit on input, too. Think about a PUT of a gigabyte file that you want to dump onto the disk. In the best of all worlds, this would map into a sendfile() from the socket to a file descriptor. >... > > 10. Call ap_get_brigade with PEEK. > > - Should this PEEK call block? Is that an option that the > > caller to ap_get_brigade specifies? I think ap_getline > > would indeed want it to be a blocking PEEK. > > If we are going to conitnue to extend input filtering, we should > probably split the mode from the blocking. Absolutely agree. Whether you have two parameters, or a single param with bitfields... *shrug* IMO, I like two params. Cheers, -g -- Greg Stein, http://www.lyra.org/
