On Mon, 13 Jan 2003, Oliver Neukum wrote: > > As far as guaranteeing that when usb_unlink_urb() returns from a > > synchronous unlink, the completion handler will have already finished -- > > so far as I can tell there is currently no such guarantee. At least, the > > There's if the unlink doesn't return an error. > > > kerneldoc preceding usb_unlink_urb() is sufficiently vague that it doesn't > > make this promise. Of course, we need to have something like this. But > > in principle there should be no problem -- or rather, the only problem is > > Not trivial. The only way to do it is to use complete_and_exit() in the > completion handler.
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(). > > 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. 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
