Re: [libgpiod] Thread safety API contract

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

On Wed Sep 13, 2023 at 10:10 PM CEST, Erik Schilling wrote:
> 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.

Summarizing a short discussion between Bart an me:

- objects created from chips are standalone and different instances can
  be used concurrently
- exception: edge_events from buffers are tied to the buffer unless one
  copies them (as stated in the docs).

Will send a patch mentioning this in the docs and adjusting the Rust
bindings.

- Erik