apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: [PATCH] bucket type "capabilities" flags
Date Wed, 20 Jun 2001 00:03:31 GMT
On Tue, 19 Jun 2001 rbb@covalent.net wrote:

> At this point, you are trying to second guess the bucket type.  If the
> bucket doesn't implement setaside, then it doesn't need setaside.

That's not true... it it doesn't need setaside, it will use
apr_bucket_setaside_noop() [which counts as an implementation for flag
purposes]; apr_bucket_setaside_notimpl() means the bucket type either
needs it and it's not done yet, or it cannot be supported by the bucket

> Those aren't benign.  Content_length has every right to call read, or
> setaside on a bucket.  So does byterange.

They have the *right* to, but that doesn't mean the necessarily *will*.

> Yes, I see how it works, but I don't believe this is the correct solution.
> How did you open the file originally?  Did you use apr_file_open, or did
> you use native calls?  If you used apr_file_open, then APR already has
> enough information to do exactly what you are doing without the custom
> bucket type.  My concern, is that you are building logic for when a file
> can be read and when it can't into a custom bucket, but that logic is
> actually very important for APR to have.  This does make the file_bucket
> slightly more complex, because now that bucket type has to handle a new
> error from apr_file_read(), but it should reduce the amount of duplicate
> code, and it removes the requirements for the flags.

Okay, I'm willing to try to implement it as an extension to the regular
file buckets.  apr_file_open() already has an APR_XTHREAD (or something
like that) flag, though only Win32 currently does anything with it.  At
any rate, getting this to work will require adding a pool parameter to
apr_bucket_file_create() as I suggested a while back; that is the pool
that should be used by file_read() to MMAP the file or to re-open it for
single-threaded reading.  I can get the filename from the apr_file_t (I
think), but I can't get that extra pool.  Note that it will generally be
r->pool for Apache purposes... but without passing it in as a parameter to
the buckets code, file_read() will have no idea which pool to use.


   Cliff Woolley
   Charlottesville, VA

View raw message