On Sun, 9 Feb 2003, Duncan Sands wrote: > > In that other driver structure, synchronizing on urb completions > > after an (async) unlink failure would either (a) have succeeded, > > because the "failure" was like the EBUSY case, "warp crystals > > would explode if we unlinked any faster", or (b) failed because > > of some HCD problem. > > > > Success means all is fine; failure (b) would be khubd hanging. > > Annoying (reboot to recover, no more modprobes) but 100% safe. > > OK, maybe we have been talking at cross-purposes then, since > I have been doing it this way (waiting for urb completion) since the > beginning (speedtouch.c). By the way, is there any advantage to > doing an async unlink rather than a synchronous one in this > situation?
This is _exactly_ the point I have been discussing off-list with David! To satisfy my curiousity, can you think of _any_ situation at all in which you would be better off doing a synchronous unlink instead of an async one, knowing that the synchronous call might return an error code and force you to wait for the completion handler anyway? At issue here is the question of how a synchronous unlink should behave. Even if it returns an error (either because the HCD refused to unlink the urb or because the urb had already been unlinked), should it wait until the completion handler has run before it returns? Alan Stern ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
