Hi,
I have noticed some behavior that I believe most users will find
undesirable. The situation is this:
1) The application opens a libusb device, which adds this to the poll fds
2) While the device is opened and IO is occurring, the device reboots or
otherwise disappears from USB
3) When the device disappears, the device's fd immediately triggers a
POLLERR condition, which is immediately seen by any active event handlers
4) At some later point in time, which varies greatly from hundreds of
microseconds to several seconds, the udev monitor will get the disconnect
notification and will then process the hotplug disconnect, removing the
device from all contexts' device list and calling registers hotplug
callbacks
5) Between the time that the POLLERR condition is seen and the udev monitor
is notified, the application gets the list of devices, which still contains
the device that has been disconnected (because it only gets removed by the
udev monitor thread, which hasn't seen the removal yet). The application
tries to open the device, but it fails with LIBUSB_ERROR_NO_DEVICE when the
open() call to the fd fails. It continues to show up in the device list and
fail to open up to the point that the udev monitor thread receives the
notification of removal.
It occurs to me that if a usb device is open and in the poll fd set, this
will provide relatively immediate notification of device removal, because
of the POLLERR condition. Once this condition is seen, immediate action can
be taken to remove the device from the device lists and notify the hotplug
callbacks. I don't know why udev can sometimes take up to several seconds
to send the event, but it is undesirable to have a device listed while it
is known to be unusable. Prior to hotplug, the described scenario would not
have occurred since the usb device tree was scanned upon every
get_device_list() call.
I have played around and have come with an improvement for this situation.
With my patch, any open devices that are disconnected will immediately be
removed from all contexts' device list and have all hotplug callbacks
called. Devices that are not currently open will still be subject to the
speed of the udev monitor and may still show up in a context's device list,
but this can also be improved to only happen at most one time. If an
attempt to open a device that has been disconnected is made, it can be
handled just like the POLLERR condition. In both of these situations, when
the udev monitor thread finally gets the removal message, it will try to
remove the device (by its session ID) but will find it has already been
removed.
Regards,
Chris
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
