On Tue, 27 Feb 2001, Greg Stein wrote: > Euh... I don't think we want another ring. > > A simpler idea is to have the apr_bucket_pool structure contain a pointer to > an apr_bucket_heap structure. At cleanup time, you do the following:
Ahh, (he says as the little light over his head comes on). This makes sense. I like. > > > > 6) Should mmap_destroy() call apr_mmap_delete(m->mmap) after when the > > > > last > > > > reference to the mmap bucket is destroyed? > > A better approach is to have the cache insert the MMAP bucket with a > refcount starting at 2 (one for the cache, one for the bucket). When the > last bucket goes away, you'll still have a refcount of 1 and the MMAP will > remain alive. Good idea. > Reading from the input filter **stack** is different. Let's say that case > (1) occurs and you've "read" the zero bytes out of the brigade. The brigade > is now empty, so you do an ap_get_brigade() for more. This drops all the way > down to the core_input_filter. It says, "sorry, I gave you everything I had" > and returns APR_EOF. *NOW* is where the EOS is detected. I confused the issue by even mentioning the filters. All I care about right now is what should be returned by the bucket read functions, which we've determined is *never* APR_EOF. If the filters want to return APR_EOF, then they're welcome to, but the buckets themselves don't. > That should do the trick. Save this MsgID somewhere :-) ;-] I figured it was more expedient to do a little research and quote what was said than to do the "well, I had this impression," "no, I had another impression" back-and-forth routine. hehe Thanks, Cliff
