From: Pete B. <pe...@ak...> - 2011-09-29 10:22:45
|
On 2011.09.28 19:09, Travis wrote: >> Tim Roberts wrote: >>> If you have your own driver, you can add a custom >>> ioctl to cancel all pending operations > > Issuing a a pipe abort request should do the trick. I'm starting to rally to that idea. Is there a way K/0 could go further than that and implement the possibility of cancelling individual OVERLAPPEDs, to have fine grained control? The more I look into it, the more I think using the driver to address this issue rather than adding a cumbersome workaround in libusb is the "right" approach. For a workaround with planned obsolescence, you want to go with KISS. Issuing a pipe abort (or finer grained abort) to the driver, and leaving the app (not libusb) with the task of re-enqueueing transfers sure looks like the simplest approach to me. Plus this would eliminate the need for handle duplication. And even if the only acceptable means of cancellation was with 0/K, asking people faced with the CancelIO() issue on XP to use 0/K instead of WinUSB wouldn't change much of anything since they have to install a driver manually anyway, and we'll have 0/K support after 1.0.9 is out. Thus the one potential problem that remains, which Orin and others highlighted, is fine grained abort of transfers. With regards to re-enqueueing, on a pipe abort, any enqueued transfer should report an error so I'm not currently seeing re-enqueuing of subsequent transfers as something we really ought to concern ourselves with in a workaround. But I'd like to know if anybody sees non-academic cases where someone, who gets coerced into a pipe abort, may not stand the cancellation of a different independent transfer that was enqueued to the same pipe. Regards, /Pete [1] http://marc.info/?l=libusb-devel&m=126861719511859&w=2 |