Hi Alan, here are my immediate thoughts, which means I didn't check whether what I say is true.
> 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? Yes, one advantage of a sync unlink is that you get an error code in case of failure which you may not get with an async unlink (for example because the urb never completes). This issue aside, you can ask the following question: if sync unlink did not exit, could a driver obtain the same effect using only async unlink (and the rest of the USB api)? In other words, is there a logical need for sync unlink, or can it be simulated? It seems to me that the answer is that the driver can obtain the effect of a sync unlink, though of course it means adding all kinds of flags, locks and code to the driver. If this is right, the interest of a synchronous unlink routine is not due to it adding missing functionality, but because it is convenient. Thus it seems to me (off the top of my head), that the correct question is: can you think of _any_ situation at all in which it would be much more convenient doing a synchronous unlink instead of an async one? (A more general question is: how best to reduce the hassle of using async unlink? Maybe a sync unlink routine is not the best way to simplify things). Well I can't right now but I do have a baby in my arms which does not help! > 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? The above reasoning suggests that sync unlink should be made as convenient as possible. However, first you have to find situations in which async unlink is particularly inconvenient and analyse them. All the best, Duncan. ------------------------------------------------------- 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
