>I added libusbhid_test_with_thread.pp to github. In that test you will notice 
>I also attempted to test sharing across threads a data structure with 
>(hypothetical) pen positions, using critical sections. Seems to work ok, but 
>more testing is needed to make sure there are no problems.

Thank you, I'll have a look!  

>The way I see this working in your particular context, would be that the 
>shared data structure would be written to/updated in the read thread and read 
>less frequently in the main thread in order to update the display.

Yes, that's the way I see it too.. data would be updated every cycle in the 
read thread, but only accessed by the main thread just before a display update, 
which would be much slower.

>-5 is LIBUSB_ERROR_NOT_FOUND - this may give a clue
>http://libusb.sourceforge.net/api-1.0/group__asyncio.html#ga685eb7731f9a0593f75beb99727bbe54

I only ever get that message if timeout is not 0... so it's the timeout's way 
of stopping things.

I suspect when the timeout time has been reached interrupt_read is calling 
libusb_cancel_transfer to stop waiting for the transfer.   It seems likely that 
what's happening is that once in a while it tries to cancel the transfer, but 
before libusb_cancel_transfer has a chance to cancel it, some data comes in 
real quick and now it's done and there is nothing to cancel.. that would 
explain why it happens only intermittently.. it just has to happen that some 
data comes in at almost the exact same time as the timeout time.  

Since this error is generated by:    LIBUSB_ERROR_NOT_FOUND if the transfer is 
not in progress, already complete, or already cancelled.   And nothing else 
could have cancelled it except the timeout, and the timeout would not have been 
issued if the transfer was in progress.. that leaves that the transfer popped 
in real quick and completed before the timeout was done calling for a cancel 
transfer.

So the question is... did I end up loosing the packet?  If this is what's 
happening... and interrupt_read timed out.. but then data came in before the 
timeout was complete.. does interrupt_read discard that data because it timed 
out so no point in doing anything with it.. or does it store the data if it 
comes in before LIBUSB_TRANSFER_CANCELLED is received.

Perhaps Linux is faster at getting the transfer finished than windows.. maybe 
windows has some buffer thing going on or?   But yes it could be an OS 
difference.

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to