On Tue, 21 Jan 2003, Oliver Neukum wrote: > > But the only alternative > > is to add a whole extra field (like internal_state). > > I believe that you should do that.
I agree. > It would be great if we could eleminate the need for handling unlinking > during completion at all. Is there a reason you cannot make them mutually > exclusive? IMHO it should be possible to do that if you make it a requirement > to call giveback with handler_lock held. Sure, that could be done. Or even easier, hcd_unlink_urb() could just grab handler_lock and hold it all the way up until the call to wait_for_completion(). That would eliminate the need for the err_out_waiting part. But I don't see this as much of a simplification. We would still need the handler_lock spinlock. We would still need to track the urb's internal state in order to prevent resubmitting unlinked urbs, double unlinking, and double submitting. In short, it would only amount to a very slight change from what I sent you before. Also, it's not an improvement performance-wise. It would mean that an unlink during the completion handler would have to spin and then actively cancel a resubmitted urb rather than just prevent it from being resubmitted in the first place. More worrisome, in my opinion, is the change in the API requirements. Besides the obvious one about not resubmitting unlinked urbs, there is a more subtle requirement: With handler_lock acquired during the completion handler, it's no longer legal for the handler to free the urb. Hmmm, maybe I should call usb_get_urb() just before the handler and usb_free_urb() just after. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
