[Rxtx] flush twice, it is a long way to the kitchen

[Gregg Wonderly]

Joachim Buechse wrote:
> I strongly opt to NOT call OutputStream.flush() in the implementation  
> of Port.close(). We COULD call it in OutputStream.close() even though  
> I would argue not to do it to motivate clean coding.
> 
> Flush has no timeout sematics. Calling OutputStream.flush() in  
> Port.close() effectively kills the only abort mechanism that exist.

I'm not sure that there is a viable abort mechanism for serial ports, see below.

> I am aware, that many Java stream implementations call flush in the  
> close. Especially the higher level ones. This is all nice and handy  
> until you see the results in the real world. Missing flush calls and  
> flushes at the wrong moment are the source of 50% of performance  
> problems in network applications. I think it's a very bad idea  
> because relying on flush to get data delivered doesn't work anyway.  

In java, by definition of the API, flush must result in all data being delivered 
to the OS.  The OS might do additional buffering for some particular types of 
I/O streams, such as by previous PIPE discussion.  But, technically, flush in 
java guarantees that no addional, pending I/O is buffered which was buffered 
before the call.

> In most out of lab scenarios only one assumption holds: If the other  
> side (receiving application, not network stack) hasn't checked and  
> confirmed it, it didn't arrive.

I think that there are numerous bad implementation of serial based software at 
the application level and at the driver level.  It is NOT in any ones best 
interest to create hurestical software designs, at the standardized library 
level, which attempt to work around such problems.  Others might develop such 
libraries and make them available as layers on top.  But, I think its important 
to draw the line for a standardized library at a very simple level so that 
everyone can get exactly the implementation details they need without having to 
wade through things that are not adding value or needed functionality.

> In my opinion a SerialPort should react like a Socket. This is the  
> closest widely known equivalent existing in the Java standard  
> distribution. Calling close on a TCP-Socket (not the Outputstream of  
> the Socket!) closes this socket immediately without calling flush.

But we have no OS support for any such activity do we.  Which Unix System calls 
would you make to affect a port close that guarantees that all pending I/O from 
other threads and all buffered I/O from all threads would be discarded, and the 
port closed?  Dealing with all of that level of multithreading and resource 
contention is an application level thing.

Gregg Wonderly