[Rxtx] well known disconnect and crash problem

[M.Dec-GM]

Hi Jason
I have had more time to do some detailed notices more :)

----- Original Message ----- 
From: "Jason Sachs" <jmsachs at gmail.com>
To: <rxtx at qbang.org>
Sent: Friday, November 05, 2010 6:45 PM
Subject: Re: [Rxtx] well known disconnect and crash problem


>
> From what I can tell, a crash error occurs under several conditions
> (environment = WinXP SP3, jar=RXTX-2.2pre1, dll=RXTX-2.2pre2),

This above looks very bad - versions mismatch !!!


> 1. Opening a port with an out-of-date CommPortIdentifier:
> a. Application enumerates CommPortIdentifiers to get valid port name Strings
> b. User unplugs USB comm port (or PC is connected to a device with a
> USB comm port that powers down)
> c. Application tries to open a comm port with a name of a port that
> was unplugged, e.g.:
>
> String portName = ... // a name of a port that was unplugged
> CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier(portName);
> CommPort commPort = cpi.open(ownerName, timeout);

My programming practice says: don't open COM port before checking if is available and/or free for use.

> 2. Writing to a disconnected port
Same notice as previous. 
In my software (on each platform) I am checking COM ports avialbility before EACH write action.
Only exception is in embedded projects where I know that port is available all the time - if properly configured.

We have discussed here about this technique a couple months ago already.
This technique prevents good my software but needs time and programming work. 
This is my hint only - based on from 25 years programming experience... - you may like it or not.
We should remember that OS's NOW are more complicated than 25 years ago, and more unexpectable things may occur....
Looking from other side - port checking is many times faster than transmission time on COM Ports.


> a. Application successfully opens a port and reads/writes to it
> b. User unplugs USB comm port

Here is the key!
OS-es AREN'T ready for dissappearing of COM ports.
In my opinion OS-es should be rewrited to create separate class: Virtual Com Ports which will better understand USB problems (dissapearing connection for example).
I think that core COM services of the OS-es still thinks that port is available ALL THE TIME - like in my embedded projects.

>
> Mariusz: Your application does not write enough characters to the port
> to cause this to occur. I have an updated application based on yours
> which does (it attempts to send 1024 characters every time the user

The question is if somebady is able to check/rewrite native code of the RXTX to prevent this problem. 
Remember that many problems are in OS-es as well (USB-VCP).
Solution in this case - re-think protocols and hardware solutions as well.
Or change interface if too many data for serial.

> p.s. just so you know, you have a few concurrency errors in your
> application. You've got synchronization locks around some but not all
> of the uses of your variables stopRead and stopWrite. (which
> technically should be instance and not static variables, as this
> breaks if you have more than one instance of the main class) It would

Of course - I have written that this piece of code for forum was prepared a long time after use, to show some ideas only :).
One variable more-less isn't important here :).
Regards
Mariusz