Re: [RFC]extension of the anchor API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Donnerstag, den 08.04.2021, 11:07 -0400 schrieb Alan Stern:
> 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:

> > 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.

OK, I will fix the description.

> 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?

That presumes that the URBs will finish in order. I don't think such
an assumption can be made.

	Regards
		Oliver





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux