Re: in.close() closes out's socket -- is this a bug?
markspace wrote:
That's pretty counter intuitive that a close does not flush. Hmm, maybe
due to latency issues networks were implemented this way. You don't
want to flush if the operation is going to stall indefinitely, just cut
off data and recover resources.
And I'm thinking about the TCP/IP stack in general here, not just the
way Java has implemented it. Java just might be calling a lower level,
native, API, which does not flush. Have to think about that though.
Morale: socket streams do not act like file streams.
I don't see any indication in
<http://java.sun.com/javase/6/docs/api/java/io/FileOutputStream.html#close()>
that it flushes, either.
I don't think this is limited to Java.
The documentation for 'FilterOutputStream#close()', the parent class for
'BufferedOutputStream' among others, makes a point of specifying that it
flushes, hinting that the omission from the docs for 'FileOutputStream' is not
arbitrary.
Now, before someone gets hyper, I realize that 'FileOutputStream#write()' is
unbuffered and normally doesn't need to flush, but the lack of such a promise
means that it is free to use non-sync system calls to do its dirty work, or to
do internal buffering on its own, and we'd have no right to complain if a
sudden 'close()' left some written things hanging.
--
Lew