java.io fix and speedup

[Jeff Sturm]

On 3 Jan 2003, Tom Tromey wrote:
> Mark> * java/io/FileDescriptor.java (position): New private field.
> Mark> * java/io/natFileDescriptorPosix.cc (write): Up position.
> Mark> (setLength): Use and set position.
> Mark> (seek): Set position.
> Mark> (getFilePointer): Return position.
> Mark> (read): Up position.
>
> With this part, what if two processes are modifying the same file at
> the same time?  I suppose even the current code has problems in that
> situation.  Is the performance of setLength and seek important?

I was wondering the same thing.   I have a local patch similar to Mark's
that mmap's a FileInputStream.  The performance of a memory-mapped
ZipFile is terrific, but it could be unsafe if someone else truncates the
file.

Given that getFilePointer can't really be trusted because it can't be
performed atomically with any other operation, I don't see any harm in
Mark's patch.

Jeff