Sleep timers can cause poor performance

[steveohara]

There are quite a few Thread.sleep() calls in the library, most without much in the way of explanation but these can seriously hamper performance if the user isn't aware.

For instance, there is a 200ms delay every time any setting is changed on an open connection, a 500ms on every port.open() call.

The settings ones we can work around (make sure everything is set before the port is opened) but the open() we can't.

[btbouwens]

Indeed! Additionally, I notice that my program is now waiting very long inside the readBytes call, e.g.:

"main" #1 prio=5 os_prio=31 tid=0x00007f82bb004000 nid=0x1703 runnable [0x0000700000219000]
   java.lang.Thread.State: RUNNABLE
    at com.fazecast.jSerialComm.SerialPort.readBytes(Native Method)
    at com.fazecast.jSerialComm.SerialPort.readBytes(SerialPort.java:413)
    at com.ghgande.j2mod.modbus.io.ModbusSerialTransport.readAsciiByte(ModbusSerialTransport.java:428)
    at com.ghgande.j2mod.modbus.io.ModbusASCIITransport.readResponseIn(ModbusASCIITransport.java:150)
    at com.ghgande.j2mod.modbus.io.ModbusSerialTransport.readResponse(ModbusSerialTransport.java:124)
    at com.ghgande.j2mod.modbus.io.ModbusSerialTransaction.execute(ModbusSerialTransaction.java:147)
    - locked <0x0000000715f4fd88> (a java.lang.Object)
    at com.amscins.thermo.HECR.readRegisters(HECR.java:167)
    at com.amscins.thermo.HECR.getAlarmRegisters(HECR.java:153)

This definitely wasn't the case with the dreaded RXTX version.

[steveohara]

I just noticed that the latest version of JSerialComm has increased the open sleep to 1 second!

[rbedemann]

I also had troubles with these sleeping timers. Would be really glad, if this point would get improved..

[hedgecrw]

The reason for the sleep timer in the openPort() method was due to a whole slew of bugs that users were experiencing without it; namely, when people would rapidly close then re-open a port, there was a chance (in some OS versions and some hardware configurations) that the either OS would freeze up, the port would become unusable, or any other number of odd port issues. This was identified to have come from the low-level OS-specific open/close calls which means that unfortunately, there's nothing anyone can do to fix those specific bugs other than to force users not to rapidly open/close a port.

I do realize this can be problematic for users who are simply trying to open a port appropriately without rapid configuration changes. As such, I've implemented an update where you can override that sleep value (or remove it altogether) when you call the openPort() method. Hopefully, this will address the concerns of both groups of users and give you all a little more control over the library. The update is already in Git and will appear in the 1.4.0 library release version.