NB: The original issue we're talking about here is #76: https://github.com/libusbx/libusbx/issues/76
On 2013.06.19 11:51, Hans de Goede wrote: > And I noticed that this patch seems wrong, if the cancel fails it does not > wait but it still frees the transfer, which at that point is still referenced > by the underlying urb, which has potentially not completed yet. No good indeed. > I see 2 options to move forward with this: > 1) Keep the patch, but if the cancel fails do not free the transfer, this is > not > really helpful, since the app could still kill the buffer the transfer > references > after we return. > > 2) Revert the patch, and re-open https://github.com/libusbx/libusbx/issues/76 > Asking the user for source for the app in question, and hunt down the real bug > there. > > May vote goes to 2, input much appreciated (iow please give me your 2 cents) ? I think at the very least, if we go with 2, we want to check the return code from libusb_cancel_transfer(transfer) and produce a warning if it's not SUCCESS. This should at least give some insight to app developers as to what is going on. Otherwise, no objection to reverting the patch and try to get more data to come up with an alternative. Regards, /Pete ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
