Re: [libgpiod] Thread safety API contract

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Wed, Sep 13, 2023 at 4:10 PM Erik Schilling
<erik.schilling@xxxxxxxxxx> wrote:
>
> On Wed Sep 13, 2023 at 3:45 PM CEST, Bartosz Golaszewski wrote:
> > On Wed, Sep 13, 2023 at 3:36 PM Erik Schilling
> > <erik.schilling@xxxxxxxxxx> wrote:
> > >
> > > On Wed Sep 13, 2023 at 2:03 PM CEST, Bartosz Golaszewski wrote:
> > > > On Wed, Sep 13, 2023 at 11:47 AM Erik Schilling
> > > > <erik.schilling@xxxxxxxxxx> wrote:
> > > > >
> > > > > Hi all!
> > > > >
> > > > > Currently it looks like libgpiod does not document any kind of thread
> > > > > safety gurantee. However, the Python bindings tests
> > > >
> > > > Indeed, the library is thread-aware but not thread-safe. Just like
> > > > what is recommended for low-level system libraries.
> > >
> > > Just to confirm:
> > >
> > > I assume this means: thread-aware in the sense that all created objects
> > > (chips, line_requests, ...) together may only be used by a single thread
> > > at once? So line_requests of a same chip may not be used across threads?
> > >
> >
> > They can be used across threads alright. Thread-aware means: no global
> > state in the library, IOW two functions won't get in each other's way
> > unless they work on the same object.
>
> Sorry, I did not phrase that question super well. A (hopefully) better
> try:
>
> If I create a chip and then open two line_requests from that single
> chip. Can I use these two line_requests concurrently on different
> threads? Or do both of them (and the chip) have to share a single lock?
>
> My assumption was that everything derived from the same chip instance
> must not run concurrently.
>

Ah sorry, I didn't understand your question. Actually using requests
from a chip concurrently in a different thread is perfectly fine. The
two structures are independent from each other in user-space and their
work is synchronized in the kernel.

Bart