Hi, On 06/19/2013 11:16 PM, Pete Batard wrote: > 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.
Done (more or less, see git). Regards, Hans ------------------------------------------------------------------------------ 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
