On Mon, 3 Dec 2001, Pete Zaitcev wrote: > [checking urb->status] > > The thread that checks for the status may get a signal and > be awaken before callback is called, but after status was set. > In that case something oopses: either the thread, or the HCA > interrupt.
Pete, sorry for the late reply - was offline some days. Thanks for the hint: yes, coming from UP, I didn't realize the status change and callback calling are differnet things on SMP. I'm just starting to think about the interesting things which might happen with a pool of urbs all using the same waitqueue for blocking - say we have all the urbs in the pool submitted (queued) to the schedule and one thread does asynch cancelation for them all on SMP - all urbs start doing concurrent status changes and callback completion which wakes up all the waiters for the different urbs at once! Am I right when believing we would need some per-urb "callback completed" flag? I mean the drv->can_read approach doesn't work with a pool of urbs to read from? What about adding "atomic_t urb->completed"? Martin _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
