All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Erik Schilling" <erik.schilling@linaro.org>
To: "Bartosz Golaszewski" <brgl@bgdev.pl>
Cc: linux-gpio@vger.kernel.org,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [libgpiod] Thread safety API contract
Date: Wed, 13 Sep 2023 16:10:10 +0200	[thread overview]
Message-ID: <CVHULP4LSR1M.U8ZIY7UL0OU5@ablu-work> (raw)
In-Reply-To: <CAMRc=MdR1coB9p1gvG2razQUeuwUJCaeDrTTm5o1ND+LJZ1SOg@mail.gmail.com>

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@linaro.org> 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@linaro.org> 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.

- Erik

  reply	other threads:[~2023-09-13 14:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13  9:46 [libgpiod] Thread safety API contract Erik Schilling
2023-09-13 12:03 ` Bartosz Golaszewski
2023-09-13 13:36   ` Erik Schilling
2023-09-13 13:45     ` Bartosz Golaszewski
2023-09-13 14:10       ` Erik Schilling [this message]
2023-09-13 15:17         ` Bartosz Golaszewski
2023-09-13 20:10           ` Erik Schilling
2023-09-21 13:06             ` Erik Schilling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CVHULP4LSR1M.U8ZIY7UL0OU5@ablu-work \
    --to=erik.schilling@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=linux-gpio@vger.kernel.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.