> > > 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
Bill, I DID specify an offset. I specified the offset 0, the start of the file. > 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 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 began. > 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. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
