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

[Mathias Dobler <mathias.dob@xxxxxxxxx>]

Am Mi., 13. Dez. 2023 um 02:08 Uhr schrieb Kent Gibson <warthog618@xxxxxxxxx>:
> 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?
Yes, exactly.

> 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.
I have one request object for 1 line 'req1' that's monitored (=wait
and read edge_events) by 1 thread 't1'. At the same time,
there lives another request object 'req2' for multiple lines, that's
monitored by another thread 't2'. My use case is, that
when t1 reads an edge event, it executes a callback that requires to
read multiple values of 'req2'. Now the dilemma occurs.
Does t1 interrupt t2 from waiting for edge events to gain the mutex,
risking t2 missing edge events while t1 holds the mutex, or does
t1 bypass the mutex and violate the libgpiod threading contract?
I think this scenario could also be boiled down to a having only 1
request for 1 line. Monitoring edge events, and at the same time
trying to read/write or other performing other operations on the
request object would result in the same dilemma.
Again, this might just be a a very specific use case with strong time
constraints (that I wish libgpiod supported out of the box).

> 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.
Hmm... sounds like an interesting challenge... and there would already
be something to look at.
Maybe a project for the future ;)

Regards,
Mathias