apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: cvs commit: apr-util/buckets apr_buckets_file.c
Date Thu, 05 Jul 2001 15:10:51 GMT

> > > 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

Bill, I DID specify an offset.  I specified the offset 0, the start of the

> 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

I am only using apr_file_* calls on this file.  The problem is that I
opened the file, then I read from it to parse the whole file.  Finally,
after finding the information I needed, I decided to put it into a bucket
with an offset of 0, because that was where the information I needed

> to ensure that your non apr_file_* calls leaves the file pointer in the proper state
> they are done.  You definitely shouldn't be horking up apr_file* calls to defend against
> this case.


Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message