[Rxtx] port in use exception - my app just won't quit

[Dr. Douglas Lyon]

Hi All,
In my previous e-mail I had fooled myself into
thinking that declaring a synchronized object as final
might have been a fix to the port in use exception.

Silly me. The problem has cropped up again.

Just as Joachim predicted, my application will not quit
when the port is in use (i.e., it cannot close the port).
The second time I try to quit, it works OK.

Try explaining that to a user. Oh wait, I am the only user ;)

This never seemed to be a problem with the internal modem
on the mac (cu.modem). And the problem only just started
when I tried using the PortIO USB driver (which is not
really new for me, either, it was just an upgrade to the OS since
I tried it).
I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think).
The note on 10.4.6 says:
"Addresses USB audio issues for PowerPC Macs; for 
example, latency is improved."

Does anybody know if PortIO USB drivers are working on 10.4.7
macs with RXTX software?
My controller is from Prolific Technology Inc.. The driver is available
from support
http://www.prolific.com.tw/
date:2006/5/22 	 	Version:v1.2.1r2

Thanks!
  - Doug


>I always appreciate a discussion based on good arguments;-)
>
>I know that Linus T. has argued several times that non-blocking close 
>does not work. However in those cases where it does not work on the 
>kernel level it can not be made to work on the application level 
>neither. In my experience it is impossible to explain to a user why 
>an application "hangs" on close. However they do understand that it 
>may hang on open.
>
>>>   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.
>
>This is the one point where I really disagree. Port.close() should 
>never be used in the meaning of OutputStream.flush(). Port.close() is 
>the only abort mechanism available. The native implementation should 
>be free to throw away unsend data on close, abort reads and release 
>the system resource as soon as possible.
>
>>>   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();
>>
>
>1st problem) This returns immediately (even in the case where close 
>does not block and returns within a few seconds). Hence the 
>application has no idea of the progress of the close, it has to join 
>the close thread or even have a callback interface to get status 
>updates. This is what I often do, but it is neither elegant nor simple.
>2nd problem) The application has to keep track of ports which are in 
>the state of beeing closed if it wants to reuse/reopen the same ports 
>(race conditions).
>3rd problem) From what I have seen the java "process" will not unwind/
>return if a java thread hangs in a kernel call (daemon or not). That 
>problem most likely affects my prefered solution as well, but the 
>above code "suggests" otherwise.
>
>>  ...implementation detail about networking.  Serial ports don't have 
>>  the same
>>  negociated close.  Close progresses, unimpeded, when the write 
>>  buffer is empty.
>
>In my experience the kernel level close may block if the USB driver 
>is trapped in a weird situation (ie a client device not reacting). It 
>may block even if no data remains to be send, I consider this a 
>kernel/driver/device bug - but unfortunately changes to the kernel/
>driver/device are often impossible.
>
>>    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.
>
>I have seen cases where unplugging a USB device at the "right moment" 
>or a buggy device that stops responding leads to a close blocking for 
>hours. This is nothing the application can influence. Arguing, that 
>an application should be allowed to hang if the OS/driver/hardware 
>has bugs works in theory but not in (my) practice. I have seen cases, 
>where (only) quitting the Java VM will unwind a hanging kernel close. 
>I can not explain this behaviour, but I can reproduce it with a buggy 
>USB device.
>
>Best regards,
>Joachim
>
>_______________________________________________
>Rxtx mailing list
>Rxtx at qbang.org
>http://mailman.qbang.org/mailman/listinfo/rxtx