[Rxtx] close != flush and may != close!
gergg at cox.net
Thu Sep 28 07:55:11 MDT 2006
Joachim Buechse wrote:
> I had a hard night because of this;-) At first sight Gregg and I seem
> to completely disagree on the matter of close. In reality I don't
> think that this is the case. I'm sure that Gregg has some practical
> experience that makes him advocate his standpoint, so do I.
> To me, this behaviour seems the best match of what is in the API and
> what is expected by the programmer:
I think that this represents a good position. In my previous postings, I was
trying to stress some of the issues about the layering of the java.io classes on
top of Port.OutputStream, which make Port completely unable to control all
aspects of the I/O flushes, except when they might eventually come into the
FilteredOutputStream or whatever wrapper is being used by Port to marry the user
level to the OS level. Then important thing for me, is to make sure that if you
are going to have Port.close be a kind of shutdown, that you understand the
issue that the OS can't really provide a guarentee of interrupt of pending
read/write activities. So, if you allow it to be non-blocking, and it returns
successfully, but the blocking threads are not awakened and the I/O calls
unwound, then the user hasn't really received any benefit from that call being
non-blocking. Instead, they experience a non-blocking behavior which might
suggest that everything is okay.
I think that if you use some sort of timed wait for the writes to abort, you can
provide some feedback to the user on the Port.close() call. But, I might just
be thinking to deep about this.
More information about the Rxtx