On Wed, Oct 10, 2001 at 06:59:32AM -0700, Ryan Bloom wrote: > do > do stuff so that we don't wait until there is data before > we process what we have now. > while (apr_bucket_read == APR_EAGAIN) > > to: > do > do stuff just like above > whild (apr_bucket_read == APR_SUCCESS && > APR_BUCKET_FIRST()->length == 0) > > Libraries should return errors, because they are valid information that the > caller can use. They also do not break the abstraction, because we have > essentially said that all bucket _can_ return EAGAIN, although anybody who > looks at the code will realize quickly that only socket and pipe bucket ever > _will_ return EAGAIN.
See, I think that's my complaint. Now, we have to always handle EAGAIN in every case where we read the buckets to be correct to the abstraction. Something just seems wrong about having to add this for a special case where we could reasonably dictate how to handle it in the special case. I have a feeling that rather than fixing this, we're just going to ditch the socket bucket entirely (what you and Greg have suggested). And, I'd rather not do that because it means that the socket bucket isn't doing what we want. And, if it isn't doing what we want, I think we need to stop and ask why. I think in the example of CORE_IN, it would just completely ignore EAGAIN and return a 0-length brigade. In my mind, that just seems the only rational decision to make there (perhaps not in the general case). The core filters should not be doing anything to slow down processing. But, I'm not sure how any reader of the buckets will know to do a select/poll/etc *without* violating the knowledge that the bucket is a socket-based bucket. Then, it'd also have to retrieve the socket from the bucket and then do a select/poll/etc on it. And, you'd have to handle the pipe case differently as well. I guess I see the violation occurring when the caller tries to "resolve" the EAGAIN not with the EAGAIN itself. The only way the caller can do that (from my understanding) is to know what the storage type is. And, that's verboten, IMHO. > Don't call a function from within a macro. You have no way of knowing how > often that function will be called. Yes, I know it is done other places in > the > code, those are incorrect too. Yeah, well, I just copied that code from a few lines below, but yeah. =) -- justin
