On Thu, Apr 08, 2021 at 11:23:05AM +0200, Oliver Neukum wrote: > 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. That's not the point. The point is that the description you wrote is incorrect. I can imagine someone who doesn't understand the details of the anchor/mooring API creating an array of pointers to URBs, then filling in those URBs in the array's order. That would mess things up if a previous kill caused the order of the anchor list to be different from the array order. How about instead of moving URBs to the end of the list when they complete, you have the anchor maintain a pointer to the most recently submitted URB? Alan Stern > > 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
