Re: [libgpiod][PATCH 3/7] tests: event: extend test coverage for reading multiple line events at once

[Bartosz Golaszewski <brgl@xxxxxxxx>]

czw., 19 gru 2019 o 15:05 Kent Gibson <warthog618@xxxxxxxxx> napisał(a):
>
> On Thu, Dec 19, 2019 at 02:48:48PM +0100, Bartosz Golaszewski wrote:
> > czw., 19 gru 2019 o 14:35 Kent Gibson <warthog618@xxxxxxxxx> napisał(a):
> > >
> > > > +
> > > > +     ret = gpiod_line_request_both_edges_events(line, GPIOD_TEST_CONSUMER);
> > > > +     g_assert_cmpint(ret, ==, 0);
> > > > +
> > > > +     gpiod_test_chip_set_pull(0, 4, 1);
> > > > +     usleep(10000);
> > > > +     gpiod_test_chip_set_pull(0, 4, 0);
> > > > +     usleep(10000);
> > > > +     gpiod_test_chip_set_pull(0, 4, 1);
> > > > +     usleep(10000);
> > > > +
> > >
> > > I assume the sleep is to wait for the event to be generated from the
> > > call gpiod_test_chip_set_pull, which is not guaranteed to occur before
> > > the call returns, otherwise you can toggle the line too fast and may
> > > miss events.
> >
> > Yes, this is why I put it there. Otherwise, some simulated interrupts
> > were being dropped when they fired while the previous ones were still
> > served.
> >
> > > Arbitrary sleeps in code, including tests, should be avoided as they
> > > are brittle and obsure what you are actually waiting for.
> >
> > Indeed.
> >
> > > An alternative in this case is to add a second event fd and wait for
> > > the event to arrive there before continuing.
> > >
> >
> > I'm not sure I understand. We can't have two event fd's for the same
> > line. Or are you thinking about setting up a second line, generating
> > events on it and consuming them so that we can rely on the timing to
> > make sure the events were registered for the first one too?
> >
>
> I was thinking of two event fds on the one line, and you are
> correct, there can only be one, so that wont work.
> Wrt using two lines, I'm not sure ordering can be guaranteed as you
> end up with two separate debugfs writes...
>

Yeah I gave it a spin and it turns out it's not reliable - some events
still get dropped albeit less than without any syncing. The usleep()
calls are still better than this. Any other ideas? I agree this is not
optimal, but couldn't come up with anything else.

Bart