[Rxtx] to flush or not to flush, that is a question
joachim at buechse.de
Fri Sep 29 03:38:44 MDT 2006
My arguing must have been horribly unclear:
All I want is a distinction between Port.close() and
- 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.
Softwarelösungen und Beratung
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:
> 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
> amount of data in the buffer.
> Please let me know if I am missing something.
> - Doug
> Rxtx mailing list
> Rxtx at qbang.org
More information about the Rxtx