[Rxtx] flush twice, it is a long way to the kitchen
gergg at cox.net
Wed Sep 27 10:01:31 MDT 2006
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.
More information about the Rxtx