On Sun, 21 Jul 2013, Nathan Hjelm wrote: > 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. > > Thinking about it you are correct. It would be simple enough: ref the > device in darwin_submit_transfer and deref the device when the > completion callback happens. My real concern is what happens in Linux > when a device disconnects? Do you get notification for each pending > transaction? If not I can add a capability flag to indicate that the OS > will handle completion of the cancelled transfers.
In Linux, when a device connects there are no special notifications for each transfer. Pending transfers are automatically cancelled by the kernel, and they complete in the usual way but with a status code of -ENODEV. In addition, the kernel refuses to accept new transfer submissions. > 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). It should always be considered a program bug to free an in-flight transfer; doing so leaves libusb holding a stale pointer. I think libusb shouldn't make any guarantee about when the user receives the disconnect notification. It might be before in-flight transfers complete or after. It might differ from one OS to another. These things generally happen in different threads anyway, don't they? With no particular synchronization. The analogous thing happens in USB at the bus level. When a device is unplugged, it can no longer reply to packets sent by the host computer. Therefore ongoing transfers immediately start to fail with an error code indicating that no reply was received (except for isochronous OUT transfers, where there's not supposed to be a reply!). However, the host doesn't learn that the device is disconnected until it polls the upstream hub for changes to the port status. Those polls take place roughly four times per second or a little faster, so there can be quite a lot of failed transfers before the disconnect is noticed. Alan Stern ------------------------------------------------------------------------------ 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
