> > 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.
It's not so simple. hcd_unlink_urb makes calls down into the hcds which
can block.
> 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.
It would keep the API completely unchanged, which is a huge advantage.
We'd make sure that you either can still unlink the "old" urb, or you are ready
to unlink the "new" urb.
> 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.
These are unlikely cases of a relatively rarely used API call.
Speed does not matter. If you are concerned with speed, concentrate
on usb_submit_urb() and giveback.
> 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,
Not true. Reference counting makes this case safe.
> maybe I should call usb_get_urb() just before the handler and
> usb_free_urb() just after.
Would not hurt.
Regards
Oliver
-------------------------------------------------------
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
