Re: libgpiod - stop waiting for events after request released

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

On Wed Nov 29, 2023 at 12:21 PM CET, Mathias Dobler wrote:
> Hi Erik!
> Thanks for the clarification and pointing me to the aspect of thread
> awareness.
> In the link to gpiod.h 2.1 you provided, it says: "Different, standalone
> objects can safely be used concurrently. Most libgpiod objects are
> standalone."
> There exists a warning annotation about thread safety on these 2 methods
> 1. *gpiod_info_event_get_line_info*
> 2. *gpiod_edge_event_buffer_get_event*
>
>  I try not to violate thread contracts, but in order to ensure that I have
> to know which object can deal with concurrency and which not. You mentioned
> the *line_request *being unsafe against multiple threads... did you have to
> go through the code to find that out, or is this maybe implicit knowledge?

The short answer is that's what the documentation says :->. The
individual line_request is standalone, but reading from it and closing
it at the same time is concurrent operation on the same object.

The long answer is that I did not know this a few months ago. So I asked
about this [1] and then added it to the docs [2].

[1] https://lore.kernel.org/all/CVHO091CC80Y.3KUOSLSOBVL0T@ablu-work/
[2] https://lore.kernel.org/r/20230928-rust-send-trait-v1-2-30b4f59d13cb@xxxxxxxxxx

> Regarding the solution about my original problem: So I guess that would
> replace the usage of *gpiod_line_request_wait_edge_events *completely,
> right?
> I would have to get the fd, poll and read events (interpret structure and
> so on) from it and write exit signals to it?

Almost, but you do not need to read from the fd on your own. You can use
gpiod_line_request_read_edge_events() and
gpiod_line_request_wait_edge_events() once you know that something
is pending. But yes, it requires a bit of leg work.

- Erik

> I am not a native C dev, so
> that would be quite a task for me... I think I might just fix threading
> access, to have only 1 thread access an object at a time, and then live
> with using timeouts on test shutdown :)
>
> Mathias