Re: [libgpiod] - fast writing while waiting for edge events

[Kent Gibson <warthog618@gmail.com>]

On Tue, Dec 12, 2023 at 06:06:54PM +0100, Mathias Dobler wrote:
> Hello Kent,
> > Don't top reply - reply inline instead.
> Sorry, still new here.
>
> > Firstly, as noted, if you are talking separate requests then they are
> > separate objects and you can do what you like.  So have one request for
> > your PWM edge generator and another for the lines to read/write.
> It doesn't add much, but just to clarify, the PWM signal is not
> generated through libgpiod, I only use line requests to read lines and
> edge events.
>

I wasn't suggesting that you were using libgpiod to generate the PWM - but
the PWM signal is being used to generate edge events, right?  And you
use a libgpiod request to receive those events?

Or are you using separate threads for lines within one request?
That is not what multi-line requests are intended for, and you would be
better off with separate requests for that case.
Multi-line requests are for cases where you need to read or write a set
of lines as atomically as possible - but you would do that from one
thread.  They can also be used where you only have a single thread
controlling several lines, so you only have to deal with the one request.
But if you want to independently control separate lines from separate
threads then separate requests is the way to go.

> > In the current implementation, the gpiod_line_request object is immutable
> > so it is safe to access it from multiple threads.
> Thanks for giving insights into the current implementation. Knowing
> this opens up a lot of easier options for synchronization, for example
> synchronizing only writes (maybe not even necessary).
>
> > Or it may be a defensive measure - in case
> > a future change makes a currently immutable object mutable.
> However, I also understand that the restrictive nature of the
> documentation could presumably be designed for changes in the future.
>
> Due to this I am a bit undecided whether I should base the C# binding
> on the current implementation, but there is probably not much else
> left for me. Even creating a separate request object for every
> individual line would not fully solve the problem to be quick in
> reading edge events and reading/writing lines of the same request
> object, while adhering to the restrictions of the current
> documentation.
>

Correct - going by the documentation the edge event handler thread
should be the only thread accessing that request.

My preference for higher level languages is to bypass libgpiod and go
direct to the kernel GPIO uAPI (the ioctl calls), which is thread safe.
Then you don't have to worry about libgpiod objects or the libgpiod API
and wrapping or mapping them to your language.
That is the approach I took for both my Go[1] and Rust[2] libraries.

OTOH I'm very familiar with the kernel uAPI (I wrote v2), which is a bit
convoluted due to the restrictions imposed by ioctl calls and kernel ABI
compatibility.  And I initially wrote the Go library to test the uAPI v2
as I wrote it, so libgpiod was not even an option then (libgpiod v1 only
supports the uAPI v1, and libgpiod v2 only supports uAPI v2).
Going direct to the uAPI also means you can support both uAPI v1 and v2,
if you want, though that is becoming less of an issue now uAPI v2 has
been out for a while.
Anyway, libgpiod is not the only option.

Cheers,
Kent.

[1] https://github.com/warthog618/gpiod (one of these days I'll get
around to renaming that to gpiocdev, but that day is not today)
[2] https://crates.io/crates/gpiocdev