On Fri, Aug 19, 2011 at 4:28 PM, Uwe Bonnes <[email protected]> wrote: >> "Dean" == Dean <[email protected]> writes: > > Dean> Out of curiosity, is libftdi (and the underlying libusb) > Dean> threadsafe? > I didn't see anything related to thread in libftdi. > So a testcase is welcome.
For libusb-1.0, you can say it is thread-safe. Please refer to the release announcement of libusb-1.0.1. http://article.gmane.org/gmane.comp.lib.libusb.devel.general/5443 Of course you need to take care of some simple things here. http://libusb.sourceforge.net/api-1.0/caveats.html +++++++++++ Blocking-only functionality The functionality listed below is only available through synchronous, blocking functions. There are no asynchronous/non-blocking alternatives, and no clear ways of implementing these. Configuration activation (libusb_set_configuration()) Interface/alternate setting activation (libusb_set_interface_alt_setting()) Releasing of interfaces (libusb_release_interface()) Clearing of halt/stall condition (libusb_clear_halt()) Device resets (libusb_reset_device()) +++++++++++ A bit more discussions here about the implementation of libusb-1.0. From where we can see that the API is not that great for Windows (some say even for Linux and Mac OS X) when it comes to async API and multithread application. It is way too complicated. http://libusb.6.n5.nabble.com/What-about-openusb-Re-patch-for-libusb-0-9-3-libusb-os-linux-usbfs-c-td5979.html http://libusb.6.n5.nabble.com/Alternates-to-libusb-tp4495537p4516596.html (the whole thread) -- Xiaofan -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
