httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Fwd: file bucket native operations
Date Tue, 28 Nov 2000 05:15:40 GMT

> But the current buckets code does seem to make this assumption, at least in the
> non-mmap case.  I'm looking at the following code snippet from file_read():
>         /* Handle offset ... */
>         if (a->offset) {
>             rv = apr_seek(f, APR_SET, &a->offset);
>             if (rv != APR_SUCCESS) {
>                 free(buf);
>                 return rv;
>             }
>             /* Only need to do seek the first time through */
>             a->offset = 0;
>         }
>         rv = apr_read(f, buf, len);
> So if the bucket initially has an offset specified, then the code seeks to that spot
> in the file and then begins reading from there with no further seeks.  That only
> works if nobody else manipulates the file pointer.  So either this does need to be a
> rule, or the above code optimization is broken.  Right?

Anytime you have multiple references to the same file descriptor, you will
have this problem.  The current code doesn't try to deal with multiple
threads using the same file bucket, because that never happens in the
current code.  Basically, we do have a rule currently that a bucket can
only be on one brigade at a time, and thus it is only accessible by one
thread.  When we start to put a bucket on multiple brigades, this
code will need to be fixed.  

As far as accessing files that have been turned into buckets from outside
the bucket code, that is perfectly acceptable, but in order to do it, the
programmer that is accessing the file without the bucket is likely to want
or need to keep their own offset variable.  Again, the whole
thread-safeness issue is a bit hairy, but it is possible.

The idea is that there are possible performance implications to being able
to just put one file into multiple buckets, but it is a rather advanced
thing to do, so simple modules won't need to worry about this.  The
modules that do want to do this will need to jump through a few hoops to
work properly.

> > That doesn't work once you try to deal with cache'ing file handles.
> I guess I've been assuming that caching file handles would be done by copying the
> file bucket.  No?

That is one possible implementation, but that is not how I would do
it.  Imagine a dynamic cache that adds a file to the cache when it is
first requested.  If we copied the buckets, then we would have an extra
bucket in the cache that is never used.  It makes more sense in my mind to
cache the apr_file_t variable, and just insert it into a bucket when the
file is requested.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message