This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: irix porting problem


>>>>> "JMC" == jmc  <jmc@cmpharm.ucsf.edu> writes:

JMC> So, does a FileInputStream always return the full length of a
JMC> file as available()?

This seems like the wrong thing to do, to me.

JMC> If the standard behavior is to return the full length (minus the
JMC> number of bytes already read), we should follow that.

This seems reasonable.

JMC> If the number can't be determined for some reason, it's better to
JMC> return 1 if we can read anything without blocking (the same way
JMC> InflaterInputStream does), so it doesn't look like we're at the
JMC> end of the file.

This seems like a reasonable fallback.

JMC> I'm not clear on whether the lseek() method of seeking to the end
JMC> of the file and back can itself cause blocking.  For systems
JMC> where FIONREAD fails on files, lseek'ing to the end would only
JMC> have to be done once, when the file was opened, so it wouldn't be
JMC> too expensive to use this method every time available() is
JMC> called.

The file can change between when you lseek it and when you return the
value.  The longer this gap, the more likely the file is to change.

We can't always reliably detect with autoconf whether FIONREAD fails
with files.  In particular, we can't detect that when we are
cross-compiling.  So the code must be written to be smart at runtime
as well (if possible).

I completely spaced that FIONREAD fails with regular files.  This
(along with select() on regular files) is one of those Unix things
that drives me nuts.

Tom

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]