[Rxtx] close != flush and may != close!

[Gregg Wonderly]

Joachim Buechse wrote:
> Well,
> 
> 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.

Gregg Wonderly