[Rxtx] to flush or not to flush, that is a question

[Joachim Buechse]

My arguing must have been horribly unclear:

All I want is a distinction between Port.close() and  
Port.OutputStream.close().
- Port.close() MUST NOT block (which means it can not flush).
- Port.OutputStream.close() MAY flush.

Regarding you question: I think that OutputStream.flush() should NOT  
timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an  
exception if Port.close() is called. Turning the MAY into a "MUST"  
can complicate the API implementation (some OSs will not unwind a  
native tcdrain call and hence a handover mechanism / background  
thread has to be used). In RXTX this thread already exists so the  
RXTX implementation would not get systematicly more complicated.

Best regards,
Joachim

---
Joachim Büchse
Softwarelösungen und Beratung
Hadlaubsteig 2
CH-8006 Zürich


On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote:

> Hi All,
> Let me see if I can summarize the discussion on flushing so far:
>
> 1. Manual Flush: A close is just a close vs.
> 2. Automatic Flush: A close is a flush and then a close.
>
> On the one hand we can define a close for a serial port
> so that it closes the serial port and has no other role. If
> data has been left in the buffer, it will be lost unless a flush
> is done explicitly.
>
> While it is the case that this would seem to speed up
> the close method, some might argue that the loss of data is
> not good software engineering, thus impacting system reliability.
> People will use:
> sp.flush();
> sp.close();
> as a serial port idiom, if close does not automatically flush.
>
> If flush does not precede close,
> the possible loss of data should be taken into
> account at the programmers' level, or it is a semantic error.
>
> Others argue that a slow serial line will delay the delivery of
> data for so long that the close will appear stalled.
>
> Corner-point: The emperor has no close.
>
> Suppose the serial device gets all stuffed up and data
> cannot be delivered. In such a case, the close will never
> finish with the flush and the serial port will never be released.
>
> In such a case, other programs (and users) who need the resource
> will be unable to access it.
>
> Digression: once I went to a wedding on a boat where the head
> was all stuffed up. Users were unable to flush and the
> OutputStream never closed... :(
>
> A serial port is a system wide resource for which many applications
> may contend. Once it is assigned to a process, in theory, no other
> application may usurp it.
>
> Wont deadlock from unreleased resources impact system reliability?
>
> So, on the one hand we adversely impact system reliability with
> increased chance of deadlock, or adversely impact system reliability
> with increased chance of data loss.
>
> To address the corner-point, the flush might need a time-out. Perhaps
> this can be computed as a function of the serial port data rate and  
> the
> amount of data in the buffer.
>
> Please let me know if I am missing something.
>
> Thanks!
>   - Doug
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx