On Mon, 13 Jan 2003, Oliver Neukum wrote: > > I disagree. How about having the core code that calls the completion > > handler manage the necessary synchronization? Of course, this would have > > to be coordinated with usb_submit_urb() and usb_unlink_urb(). > > Yes, this is the other option. I tried to implement that. > Did you have a look at the patch ?
I'm afraid not. My familiarity with the Linux USB kernel interfaces does not extend to the implementation -- I wouldn't be able to follow your patch without a lot of study first to learn how the current code is meant to work. > > > > dealing with the case that the handler resubmits. What happens if the > > > > handler resubmits the URB, and another thread tries to unlink the > > > > newly-submitted incarnation before the handler has returned? > > > > > > We must make sure that an interrupt handler is not reentered. > > > > So some type of synchronization of this sort is necessary in any case. > > Well, it's a hard problem. We might need a counter or something similar. > It's a difficult problem I hadn't thought of. Maybe an additional spinlock would help. It could be used by the completion handler, the interrupt handler, and usb_unlink_urb(), but not by usb_submit_urb() -- thereby permitting the completion handler to resubmit. (Or maybe your patch did something like this. Now I wish I had tried to read it.) Alan Stern ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
