From: Pete B. <pe...@ak...> - 2011-09-29 00:43:53
|
On 2011.09.29 01:29, Orin Eman wrote: > On Wed, Sep 28, 2011 at 10:55 AM, Peter Stuge <pe...@st... > <mailto:pe...@st...>> wrote: > > Tim Roberts wrote: > > > I was very surprised to see that the code for cancelling a transfer > > > only seems to work completely on Vista and later, because of > > > CancelIoEx() availability there. Is there really no solution > for XP? > > > > Not out of the box. If you have your own driver, you can add a > custom > > ioctl to cancel all pending operations, but prior to Vista, you can > > only cancel I/O operations from the same thread they were issued. > > The obvious solution would be to submit all io from one or more > libusb-internal threads. This would cost a small bit of overhead, but > maybe it would be tolerable in return for the API working right? How > expensive is life with threads in Windows? > > You'd have to create a thread per pipe - CancelIo() cancels ALL pending > operations on a handle that were issued by the calling thread. Except I already have a workaround for that in poll_windows.c, which is to duplicate the handle for each request (each overlapped we create), so that they can be cancelled individually without interfering with one another, thus I think the single thread workaround should work. As far as I know, duplicated handles, even from the same origin, can work around this limitation. > Then you > still have problems if the user wants to cancel the n'th request and the > 0..n-1'th requests haven't completed - you'd have to wait for them to > complete before you could call CancelIo(), and of course, transfers > issued after the one the user wants to cancel get cancelled as well, so > you'd have to reissue those. Unless I'm mistaken, this shouldn't apply with duplicated handles. Regards, /Pete |