Re: libgpiod - stop waiting for events after request released

["Erik Schilling" <erik.schilling@xxxxxxxxxx>]

On Tue Nov 28, 2023 at 6:21 PM CET, Mathias Dobler wrote:
> Hello,

Hi!

> I am writing a C# binding for libgpiodv2. There are some automated
> tests that keep failing due to the fact that each test uses the event
> handling functionality of libgpiodv2. First it creates a request, then
> starts a thread to handle edge events, does some operations on line/s
> which causes edge events to be created, and in the end releases the
> request. When the next test starts, it get's an "Error: Device or
> resource busy"
> I checked the freeing logic and could find out that the reason lies
> within the event handler thread that is still waiting on
> gpiod_line_request_wait_edge_events that returns only when the timeout
> appears. My expectation was that when the request gets released,
> gpiod_line_request_wait_edge_events  would immediately return without
> timing out, but that is not the case.
>
> So my question is, is that by design?

The root problem here is that you are violating thread contracts. The
hosted docs are not updated to 2.1 yet, but thread safety documentation
got added here:

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/include/gpiod.h?id=055d401f88a6c0bb8f2ccd3773154baac991075b#n46

  libgpiod is thread-aware but does not provide any further thread-safety
  guarantees. This requires the user to ensure that at most one thread may
  work with an object at any time.

While you are in gpiod_line_request_wait_edge_events you may not call
any other functions on the line_request from a different thread. So you
may not close it while waiting. Of course knowing this does not help
your particular problem :).

> If yes, and there is no interest in changing it, I would find ways
> around it, like waiting on the timeout but that would force me to set
> it very low, to not delay the tests too much.

The best way to solve this is to have your own exit signal. You can open
a pipe, eventfd or alike and use gpiod_line_request_get_fd [1] to
get the filedescriptor that libgpiod uses. Then you can do your own
polling. Triggering a event on your signaling fd then exits the poll
immediately without having to use timeouts. See also a recent
discussion [2] that originated in a similar confusion.

Maybe it would help to add some documentation on the wait functions...
While this is a common pattern with system libs, I was also confused by
the same problem when I first needed an immediate shutdown.

[1] https://libgpiod.readthedocs.io/en/latest/group__line__request.html#ga5c0dbdcd8608b76e77b78bca9a6b03d7
[2] https://lore.kernel.org/r/20231113143219.43498-1-zinger.ad@xxxxxxxxx

- Erik