On Thu, 17 Jul 2003, Pete Zaitcev wrote: > The urb->lock is situated in the same chunk of storage > as the urb->status, so it only can protect the status if > there is no hazard of deallocation of the urb. However, our > API makes no such guarantees across the call to the ->complete. > Therefore, urb->lock cannot be held across the callback. > Once it cannot be held across the callback, there is a > window for the upper layer to peek at the urb after the > end of transfer and before the calback proper, and then > it's an oops.
You've really puzzled me, even if David understands. You seem to be saying that there's a danger of the URB being deallocated during some window after urb->lock has been released but before the completion handler is called. Is that what you meant? Just in case it is, let me point out two things. First, urb->lock is only held during part of the time the core and the HCD own the URB; there's nothing special about that window immediately preceding the completion callback. Second, who's going to deallocate the URB? Not the core or the HCD -- they never deallocate URBs. Only the driver might (is that what you meant by "the upper layer"?). But a properly-written driver won't touch the URB _at all_ once it has been submitted until the completion callback. So I don't see what the danger is. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
