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

Reply via email to