[Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts!
Steffen DETTMER
Steffen.DETTMER at ingenico.com
Tue Mar 29 03:43:26 MDT 2011
> ports.clear();
> different threads. Developer A has the above code and then does this:
>
> ports.add("/dev/myspecialport");
>
> ...because maybe he knows the port name will always be the
> same and doesn't want to bother with any others.
Yes, Java loves singletons and singletons are evil.
But People love evil Java interfaces. Some even consider InputStream
suited for something. And in fact, in practice it turns out that it
usually does work :-)
> But the Developer B doesn't know this and is surprised to
... to find a system with /dev mounted elsewhere? Or without ttyS*?
But what if the admin had a reason to shot himself in the foot?
> find that, upon repeated testing, the Set returned by
> rxtxCommDriver.getPortIdentifiers() contains either 1) the
> expected Set of ports, 2) an empty Set, or a Set containing
> only "/dev/myspecialport".
The ownership model is incomplete in such cases.
Unfortunately, Java disencouradges to consider ownerships, also caused
by the forced Garbage Collection and the absense of resource-freeing
destructors. But this is a known habbit, so someone can expect
developers to know that :-)
BTW, Google Go has interesting ideas also on that topic.
> All three scenarios are possible
> with the code as it stands now since the ports Set in
> RXTXCommDriver is static, both threads are working against
> the same Set, and there's no guarantee as to when Developer
> B's code which iterates over the set will run...either before
> Developer A's ports.clear(), after ports.clear() but before
> the ports.add(), or after the ports.add().
Yes, and the same for /dev/.
Ohh, you could run a second instance in a chroot, ok.
But in the same way you could also run a second VM. In case of chroot,
you even have to run a second VM.
(I'm just trying to show that there are no guarantees but in fact most
are assumptions, when considered in full and that in the end some
conventions usually must be met).
oki,
Steffen
More information about the Rxtx
mailing list