nyholku / purejavahidapi

Other
122 stars 69 forks source link

Hang in close() when successive open/close #52

Closed AlainCo closed 4 years ago

AlainCo commented 6 years ago

Hi,

I'm using purejavahidapi on windows, doing sequence of HidDevice.openDevice, then setOutputReport, then I receive a callback in the InputReportListener.onInputReport and inside the onInputReport I do a HidDevice.close() (maybe that is the trick, I do that in a completableFuture.whenComplete() )

the first exchange is OK but the second exchange hang in the close() probably in the m_SyncShutdown.waitAndSync();

I've modified my code so that the close is done out of the InputReportListener.onInputReport and there is no problem.

anyway there is a problem of synchronisation between close() and the runReadOnBackground() thread

I dont understand the m_SyncShutdown.waitAndSync() call, so I cannot understand the problem...

nyholku commented 6 years ago

Hi, I don't have to time to go to this deeply. However the idea of waitAndSync is that two or more threads can synchronise their execution at the points where they call waitAndSync. Neither thread will proceed from waitAndSync call until both have called waitAndSync. Then number of threads that need to be synced is passed in the constructor of the SyncPoint object.

AlainCo commented 6 years ago

OK, I will look if I can understand the sync problem, but now I avoid it. Thanks.

nyholku commented 6 years ago

The basic isssue is that it is not supported to call close inside the InputReportListener.onInputReport listener. I don't have time atm to analyse this further if this is something I want to allow/support. The difficulty is that the on inputReport is called from within the thread that the other thread will be waiting to synchronise and thus there is a logical deadlock.

The way this should be implemented is that the if close is called from within the input listener then the close should only set a flag and when the input listeners returns that flag is checked and if the close is performed. However there details there that are no trivial to take care of. Further this will modify the contract of close because if implemented like that then device really isn't close until later and not when close returns.

I would suggest that you do not close the device from within the listener.

AlainCo commented 6 years ago

I close out of the callback that now, and I understand now why the way I dit it before was wrong.

nyholku commented 4 years ago

Closing this now as I'm slowly trying to get back to keeping up PJHIDAPI