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

[Kent Gibson <warthog618@xxxxxxxxx>]

On Thu, Dec 19, 2019 at 03:07:10PM +0100, Bartosz Golaszewski wrote:
> 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.
> 

The two options I can think of are getting the debugfs write
to block until the simulated interrupt has been serviced, or adding a
multi-line set to the mockup so the two lines can be set simultaneously.
I'm not sure the first is possible.
And the second wont help if it results in two interrupts unless the
order the interrupts are serviced is guaranteed.
Either way it seems like a whole lot of work just to remove the sleeps,
so the sleeps seem like a reasonable workaround :(.

Kent.