On Fri, Aug 19, 2011 at 4:28 PM, Uwe Bonnes
<bon@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> "Dean" == Dean <dean@xxxxxxxxxxxxxxx> 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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
