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

[Joachim Buechse]

It can not be guarenteed that all data is discarded, neither can it  
be guarenteed that any remaining data will be send.

What is important, is the fact that closing a TCP-Socket on any OS I  
have seen and in Java will abort reads+writes. It makes little sense  
to model SerialPorts differently.

Regarding your question:

Writes from threads need to happen in a synchronized manner (via  
semophores, not synchronized methods). This is trivial as a semaphore  
is needed anyway to deny write after close on the Java level.

Hence, at any time you will have a maximum of 1 thread blocking in  
write. A call to close first sets the "closed" flag/semaphore. No  
other threads will enter afterwards.

If there is no blocking write, tcflush (POSIX) discards all unsend  
data. If there is a blocking write tcflush may block as well (on OS  
X) - so that doesn't help. While some OS kernels will not abort a  
blocking write when an asynchronous close happens, most will. The  
trend in newer versions is clearly to abort and unwind the write. If  
an OS blocks on fd.close until (an already blocking) write has  
finished sending all data, the fd.close should be delegated to the  
writing thread (or some other thread, in RXTX this could be the drain  
thread).

This guarentees that Port.close() will return in a controled manner.  
The thread calling Port.close() can (and should) join if another  
thread is taking control of the actual closing. However in my opinion  
this join should have a relatively short timeout.

Regards,
Joachim


On 27.09.2006, at 18:01, Gregg Wonderly wrote:
>
> 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
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx