Re: [libgpiod] Thread safety API contract

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

On Wed Sep 13, 2023 at 5:17 PM CEST, Bartosz Golaszewski wrote:
> 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.

Ah. That makes things a lot simpler. I think then we only need some
Send traits on the Rust structs. Does the same guarantee apply to all
structs that are "created" from a chip? Then I would look into whether I
can extend the docs while fixing the Rust bindings.

Thanks again!
- Erik