Re: [RFC]extension of the anchor API

[Oliver Neukum <oneukum@suse.com>]

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