apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: cvs commit: apr-util/buckets apr_buckets_file.c
Date Thu, 05 Jul 2001 14:28:56 GMT

> On Thu, 5 Jul 2001, Bill Stoddard wrote:
>
> > I am teetering on a -1 for this patch. You are hacking around a more fundamental
problem.
> > If we cannot fix problems like this w/o impacting the performance of all applications
that
> > need to read files, then APR is seriously broken.
>
> Huh?  If I have a file that I put into a bucket, and I set the offset to
> 0, so that the bucket refers to the whole file, then the bucket code needs
> to respect that, regardless of what else I do with the file.  This is
> about making the code orthogonal, so that if I read from the file
> someplace else, it doesn't effect my bucket logic.
>

If you perform a read on a file and don't specifiy an offset, then you should assume you
will be reading from the current file pointer maintained by the system (or by apr_file_t
in the XTHREAD case).  If you have an apr_file_t open and you are reading from the file
someplace else using the fd, then you are screwed. You shouldn't be mixing apr_file_*
calls with non apr_file_* calls on the same fd. If you insist on doing this, then you need
to ensure that your non apr_file_* calls leaves the file pointer in the proper state when
they are done.  You definitely shouldn't be horking up apr_file* calls to defend against
this case.

Bill



Mime
View raw message