apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: apr-util/buckets apr_buckets_file.c
Date Thu, 05 Jul 2001 22:47:38 GMT
On Thu, 5 Jul 2001, Roy T. Fielding wrote:

> Either define two different file bucket types or add a variable that
> indicates relative vs fixed.  Fixed fds have to be seeked to the
> position of each read, whereas relative fds skip from the current
> position to the offset.  File buckets are therefore relative until
> split.

I thought about that.  But there'd be a *lot* of code duplication.  The
only thing that would be different would be whether or not apr_file_seek()
gets called and the logic to convert from one type to another.  Plus I'm
not convinced that there's any reliable way to know when to do the
relative->fixed swapover.  It's not just when you split() the bucket.
Problems can occur with copy, split, and delete, at least.  But just the
fact that you copy, split, or delete doesn't mean that you HAVE to seek,
it just means that you can no longer guarantee that you don't have to

It seems like it'd be a lot easier if we just stuck a conditional at the
top of apr_file_seek() that returns immediately if the offset stashed in
the apr_file_t (which is assumed to be the same as the one in-kernel,
which is a valid assumption if you don't mix apr_file_* and non-apr_file_*
calls on the same file handle) is the same as the offset passed into
apr_file_seek().  So we're talking about one functional call and one
conditional return.  It's a tradeoff between that very small performance
penalty and much cleaner and more reliable file buckets.

I'm dislike the idea of duplicating the file buckets in this way.  But I'm
willing to change my mind if you can show me a way to do it that doesn't
duplicate much code and that works in all cases.  <shrug>


   Cliff Woolley
   Charlottesville, VA

View raw message