Am Donnerstag, den 25.03.2021, 14:38 -0400 schrieb Alan Stern: > On Thu, Mar 25, 2021 at 05:04:25PM +0100, Oliver Neukum wrote: > > Am Donnerstag, den 25.03.2021, 11:06 -0400 schrieb Alan Stern: > > > > +:c:func:`usb_submit_anchored_urbs` > > > > +--------------------------------- > > > > + > > > > +The URBs contained in anchor are chronologically submitted until > > > > > > "chronologically" is the wrong word. They are submitted in the order > > > of the anchor's list, which is the same as the order that an iterator > > > would use. > > > > OK. "In the same sequence as they were anchored" ? > > Hmmm. What happens if you submit an anchor's worth of URBs, but then > you kill them in the reverse order (which is how you would normally want > to cancel a bunch of URBs)? Since each URB gets moved to the end of the > anchor's list when it completes, after they are all killed the list will > be reversed. So the next time you submit the anchor, the order of URBs > will be backward. If some of the URBs completed before they were > killed, the order will be mixed up. Yes. If the URBs themselves, as opposed to their payloads, are different, this will happen. Yet I am afraid we are looking at a necessary race condition here. If you cancel a non-atomic operation, you will need to deal with all possible intermediate stages of completion. > Of course, if you never use the URBs on an anchor after killing it, this > doesn't matter. Yes, to partially solve this issue I wrote usb_transfer_anchors() which allows you to separate those URBs you kill (or submit) by shifting them to another anchor. This is incomplete, as obviously something you kill may do a transfer. Regards Oliver
