Hi,
I see from the git log that the hotplug_poll() function was added for
applications that perhaps handled hotplug notification on their own. Given
the structure of the new hotplug code, it appears that a context will not
be successfully created unless the hotplug monitoring thread can be
created. So one can assume that if a libusb context was created, a hotplug
event thread is running.
Since the netlink or udev fd is being monitored by poll() in the hotplug
event thread, this is the first path for receiving a hotplug event. The
hotplug_poll() function then adds a second path to receive a hotplug event.
It appears to me that the only time the hotplug_poll() function will ever
get to enumerate a device is in the following situation:
There is a pending netlink or udev message to read. The hotplug_poll()
function is called before this message is received and acquires the
linux_hotplug_lock before the hotplug thread does so, effectively
"stealing" the message from the hotplug event thread.
The only way I see this situation occurring is in either of the following
cases:
1) A hotplug event occurs right when some call to libusb_get_device_list()
comes in. The hotplug_poll() function enters and grabs the
linux_hotplug_lock before the hotplug event thread can. The hotplug event
thread may not have returned from poll() yet, or it may have returned from
poll() but didn't acquire the linux_hotplug_lock in time.
2) Two or more hotplug events occur. While the hotplug event thread is busy
handling one, the hotplug_poll() function enters and then waits to acquire
the lock. As soon as the hotplug event thread is done handling the first
event, it will release the lock and go back to poll(), giving the
hotplug_poll() function the opportunity to service the next hotplug event.
I do not fully understand why this second path is necessary. If the idea is
that a device may take a long time to enumerate, the structure doesn't help
this because the linux_hotplug_lock is held for the entire duration of the
enumeration/disconnect process, thereby blocking the other path from
handling anything at the same time.
Can someone please clarify the purpose/reasoning?
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
