Use libusb-1.0 report of pollfd's in NUT main loop #2747
Labels
enhancement
USB
Windows
Windows-not-on-par-with-POSIX
Aspect of Windows builds known to be dysfunctional compared to POSIX builds; fix needed to be on par
Milestone
As discussed in #2742 (comment) a NUT driver (any one of them) does some work in
upsdrv_updateinfo()
, effectively sleeps for the remainder oftimeout
indstate_poll_fds()
(if noextrafd
like those for a serial port or a raw network socket gets bytes incoming, or asockfd
internal todstate.c
), and only then gets to runupsdrv_updateinfo()
again and perhaps notice the absence of the device as reported by libusb.NOTE: Currently
extrafd
is ignored in WIN32 builds, but we do handlesockfd
so this might be extensible eventually. See also https://learn.microsoft.com/en-us/windows/win32/winsock/select-and-fd---2Currently this shortcut is not really used by the majority of drivers, so they normally all "suffer" a standard delay between loop cycles, with the few hits being:
As documented in https://libusb.sourceforge.io/api-1.0/group__libusb__poll.html#ga54c27dcf8a95d2a3a03cfb7dd37eae63 and https://libusb.sourceforge.io/api-1.0/structlibusb__pollfd.html the LibUSB-1.0 API actually allows programs to see the collection of file descriptors (and their event flags from
poll.h
) associated with a context, so we have a chance to redesign driver loops (not sure OTOH there's one or moreextrafd
equivalents in our case) in such a way that we can react more quickly to USB device events. Note there does not seem to be any similar facility in older LibUSB-0.1 headers.This idea may also help with #2609 as well.
The text was updated successfully, but these errors were encountered: