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)
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
