From: Andrew S. <str...@as...> - 2009-05-28 21:47:25
|
Daniel Drake wrote: > David Moore wrote: >> From: David Moore <dc...@ac...> >> >> libusb_control_transfer and libusb_bulk_transfer are designed to be >> synchronous such that control is not returned until the transfer >> definitively succeeds or fails. That assumption is violated if a signal >> interrupts these functions because there is no way for the application >> to continue waiting for the transfer without resubmitting it. This >> patch changes these synchronous APIs so they do not abort in the case of >> a signal interruption. > > Thanks for the patch. What kinds of signals are you dealing with here? I have a vendor supplied library which uses signals to communicate internally between threads. Unfortunately, these signals also interrupt any syscalls one might happen to be in in one's own code. Thus, whether libusb gets syscalls interrupted with EINTR is not up to me when using both the vendor library and libusb, both of which I'd like to continue to do. FWIW, the vendor library is the camera driver "PvAPI" by Prosilica, available at http://www.prosilica.com/support/gige/ge_old_sw.html (I have tested with 1.16 and 1.18). You do not need a Prosilica camera to experience this behavior. Simply calling PvInitialize() should be enough to elicit the periodic (about 1/sec) signals. > Just trying to think if there is any situation where we would want this > interruption behaviour, but I can't immediately think of any, and > libusb-0.1 seemed to be "uninterruptible" in the same sense too... I haven't tested that. -Andrew |