[Rxtx] port in use exception

[Gregg Wonderly]

Joachim Buechse wrote:
> In the case of closing a socket/port I (partly) disagree with Greggs  
> statement.

There are a number of issues to consider, so I appreciate your view points 
against mine!

>  From a user perspective, closing a resource means "I lost all  
> interest in you". In the case where the (synchronous) close is  
> immediate that is no problem. However in the case where it is not,  
> this creates big problems. The application by itself has basicly no  
> means of dealing with a blocking close. As the user has lost interest  
> in the port he will not understand any kind of dialog regarding an  
> already closed port, he might have even decided to close the  
> application and see that it "hangs" on close.

It is possible for a java application to do

Thread th = new Thread() {
	public void run() {
		try {
			port.close();
		} catch( Exception ex ) {
			log.log( Level.WARNING, ex.toString(), ex );
		}
	}
};
th.setDaemon( true );
th.run();

and be in complete control of the asynchronous nature of the call, and not be 
bound by the OSes delay in closing.  This, then makes it necessary for the 
application to track this pending close.  It could, use a Future, to track the 
pending close, and force the block on open.  But, this should be an application 
level design decision, not something that is the only interface to the 
underlying system calls.  That's my request anyways.

> The right place to treat this is on the open. This is where you have  
> the attention of the user and this is the point where it makes sense  
> to wait. TCP/IP uses the same mechanisms. The kernel will keep  
> connections in CLOSE_WAIT until complete shutdown or timeout without  
> obliging the application/user to wait.

There are a couple of issues here.  One, is that for network operations, an open 
port is distinctly different from a listening port.  And if the listening port 
remains listened to, it can be opened multiple times, compared to a serial port 
which should typically not be shared/opened multiple times.  CLOSE_WAIT means 
that the port has been closed, and the OS is holding the port in that state so 
that any attempts to reuse the port or otherwise send related traffic, will 
allow the OS to send a TCP_RST back to close down the offending application's, 
continued use of that port after the agreed apon close.  This is all 
implementation detail about networking.  Serial ports don't have the same 
negociated close.  Close progresses, unimpeded, when the write buffer is empty. 
  If remote flow control is asserted, there is no negociation for relief.  This 
is why it seems interesting, to let the close happen asynchronously.  In single 
threaded programming environments, it becomes very convenient to do this, but I 
don't think it's a correct behavior.  When serial hardware/software is broken, 
and the flowcontrol never subsides, the application can hang forever.

So, it might be good to have the timeout on close, but still, that value can be 
problematic under situations of large amounts of data at very slow rates.

> Close is the natural "abort" for other blocking operations. Making  
> close synchronous will make it block. Having the close block gains  
> basicly nothing (from a user perspective) and makes the  
> implementation of abort and application termination more complicated.

Close is an operating system detail, and rxtx, should maintain reasonable 
separation between what an OS provides (sync/async close) and its API.

>  From my experience a usefull implementation for close is a timeout  
> based synchronous close with a rather small timeout. If the close  
> "works" (ie no kernel/driver problem preventing it's execution) wait  
> until it has returned. If it blocks (ie more than 1..4 seconds)  
> return from the call. The trend for the kernel implementation of  
> close is clearly "abort" r/w operations. It used to be wait for the  
> end of r/w operations.

Well, serial data can flow slowly compared to what a program can generate. So, 
it should be possible for an application to open a port at 300baud, send some 
large amount of data and block on the close, waiting for the send to complete.

Gregg Wonderly