Question regarding the behavior when O_NONBLOCK is absent

[Nayan Deshmukh]

Understood. Thanks for the clarification!

On Sat, Jun 4, 2022 at 11:44 AM Peter Hutterer <peter.hutterer at who-t.net> wrote:
>
> On Sat, Jun 04, 2022 at 10:59:07AM +0900, Nayan Deshmukh wrote:
> > Hello,
> >
> > The libevdev requires that the fd should be opened with the O_NONBLOCK
> > flag. What kind of behaviour can we expect if we try to create a
> > libevdev device without the O_NONBLOCK flag? The main question is
> > whether it will be blocked or it could be undefined behaviour as well.
> >
> > A little background, I have written libevdev bindings in rust [1] and
> > I wanted to document the kind of behaviour people should expect and
> > whether I should mark the function as unsafe if it were to exhibit
> > undefined behaviour.
>
> no worries there, it's well-defined behaviour, but you should use the
> LIBEVDEV_READ_FLAG_BLOCKING  flag in libevdev_next_event(). Reason being
> that libevdev tries to read more events from the fd to cache them whenever
> you call that function [1], which means if the fd may block even when more
> events are already cached and ready to be returned. With that flag you
> disable that part, so reading only blocks when there are no more events
> cached and we really need to read from the fd.
>
> IOW, the code is (very) roughly like this:
>
>         def libevdev_next_event(self, flags):
>            if self.queue.is_empty() || flags != READ_FLAG_BLOCKING:
>                    self.queue.append_events_from_fd()
>
>            return self.queue.pop(0)
>
> Cheers,
>    Peter
>
> [1] goal is to avoid SYN_DROPPED even when processing of any specific event
> takes a bit longer