CCID handling of multiple devices
Maksim Ivanov <[email protected]>
| Newsgroups | gmane.comp.lib.muscle |
|---|---|
| Message-ID | <CAH=wB8xFDULchdDuA6zWoO=_yFurtjgXkfYwH9wxYEYnpchwiQ@mail.gmail.com> |
Hello, Looking at the CCID source code, it seems that there may be some problems with working with multiple readers simultaneously. The CCID reader polling code (or, to be precise, its libusb-based version) is based on the libusb_handle_events function: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=pcsclite/CCID.git;a=blob;f=src/ccid_usb.c;h=6a097eadb821ebed39eefac6c4b39b3f8f135001#l1252 The problem with this function is that, as it's documented in libusb docs, it's prone to race conditions: http://libusb.sourceforge.net/api-1.0/mtasync.html#Using Seems that the races are pretty likely to occur when there are two or more readers operated simultaneously. For each of them, a thread with a polling transfer is created by the CCID driver; each thread is blocked on libusb_handle_events most of its time. The first type of race may happen between checking the "completed" variable and calling the libusb_handle_events function: another thread with the running libusb_handle_events function may finish this transfer during this period of time. The second type of race roots from the fact that there is no guarantee which thread's libusb_handle_event will catch the events, so it may be that one polling thread misses the transfer completion it's waiting for. Even though the races, when they occur, result in just 60 seconds delay, it would be great if they would be omitted completely. The fix shouldn't be difficult, based on the handy function libusb_handle_events_completed, which appears to be solving exactly this problem: http://libusb.sourceforge.net/api-1.0/group__poll.html#ga0bc99f39e4cf5ad393cd5936c36037d1 Thanks, Maksim