[fpc-pascal] USB Human Interface Devices
Jean SUZINEAU
Jean.Suzineau at wanadoo.fr
Wed Aug 28 17:00:29 CEST 2019
Le 28/08/2019 à 13:26, James Richters a écrit :
> Thanks for figuring out the critical section needs to be initialized. Stefan's example did not do this:
> https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp
>
> maybe it's something you can get away with on Linux...
Maybe, it seems EnterCriticalSection is defined by the current thread
manager. But if your variable is uninitialized, you can have anything in
it, I think EnterCriticalSection cannot do anything reliable with it.
> I'll put in the init and done. Should I enter critical section only for writing to shared variables, or also when reading them?
You don't need to enter the Critical section to read the variable.
The critical section is essentially used to prevent the case where your
main thread and your read thread write two different values to the same
variable at the same time. In this case without a critical section, you
cannot predict the value of the variable. If the variable is always
written by the same thread, you don't need the critical section.
> I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running. I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists.
You can find whether your thread is running or not with the
readThread.Suspended property,
but in your program, your thread is always running, it's nether
suspended. It's just blocked in a call (to libusbhid_interrupt_read I guess)
More information about the fpc-pascal
mailing list