On Mon, Aug 28, 2017 at 12:38:08PM -0400, John Ferlan wrote: > > > On 08/24/2017 07:23 AM, Erik Skultety wrote: > > The event loop may get scheduled earlier than the udev event handler > > thread which means that it would keep invoking the handler callback with > > "new" events, while in fact it's most likely still the same event which > > the handler thread hasn't managed to remove from the socket queue yet. > > This is due to unwanted increments of the number of events queuing on the > > socket and causes the handler thread to spam the logs with an error about > > libudev returning NULL (errno == EAGAIN). > > > > Signed-off-by: Erik Skultety <eskul...@redhat.com> > > --- > > src/node_device/node_device_udev.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > And by disabling the polling couldn't we miss an event? That would be > really bad if the event after the one we miss relies on the event we > missed creating something that the subsequent one would need (if that > makes sense).
No, we just don't poll on the @fd for a moment, but the data has kept being delivered to the udev monitor and waits for us to be extracted. Erik -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
