On Jul 21, 2013, at 8:11 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Sun, 21 Jul 2013, Nathan Hjelm wrote: > >> A little more detail about what is happening in this case. When the >> device gets disconnected the hotplug backend calls >> usbi_handle_disconnect which then �completes� (makes all outstanding >> transfers as failed) all in-flight transfers. The darwin backend then >> gets notification for the OS that transfer(s) have failed. This is >> tricky to deal with because the user may have: freed the transfer, >> released the device, etc. I think the best course of action is to >> leave the hotplug backend code in place and �complete" any >> outstanding transfers and then ignore the completion callback from >> the OS. I should have the patch ready later today or sometime >> tomorrow. > > Are you sure this is the best approach? IMO it would make more sense > to mark the device as gone when the disconnect notification is > received, but leave the transfers intact. They will soon fail all by > themselves, and the OS completion callbacks can be handled in the usual > way. After all the transfers are gone, then it will be safe to finish > the disconnection procedure. Forgot to comment on sending the disconnect after all transfers are gone. Do you think there would be a problem with the user getting the disconnect then the associated transfer failures? We could define the semantics of disconnect to be that the transfer completion callbacks are always called with the appropriate error code. It could be considered incorrect program behavior to free any in-flight transfers before the callback (in the disconnect case). -Nathan ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
