This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: java.io fix and speedup
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Mark Wielaard <mark at klomp dot org>, <java-patches at gcc dot gnu dot org>
- Date: Fri, 3 Jan 2003 13:08:24 -0500 (EST)
- Subject: Re: java.io fix and speedup
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