public inbox for linux-gpio@vger.kernel.org
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Mathias Dobler <mathias.dob@gmail.com>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>, linux-gpio@vger.kernel.org
Subject: Re: [libgpiod] - fast writing while waiting for edge events
Date: Wed, 13 Dec 2023 21:12:30 +0800	[thread overview]
Message-ID: <ZXmtvuhehSkt7r9i@rigel> (raw)
In-Reply-To: <CAEydid=fgJNfmx41HLdaf27oa+5QWqqVr69DgiQHGaxfy95P7Q@mail.gmail.com>

On Wed, Dec 13, 2023 at 01:52:47PM +0100, Mathias Dobler wrote:
> > Firstly note that you cannot lose edge events. They are queued in the
> > kernel in case userspace is a bit busy.  It is still possible to overflow
> > the queue, but it takes serious effort.  You can check the seqnos in the
> > events to detect an overflow.
>
> I think the only thing that is lost is my memory sometimes.
>
> > It is also a bit odd to be monitoring a line for edges AND polling it
> > at the same time.  You get edge events when it changes value, so polling
> > between edges is redundant.
>
> Yeah, I might have to rethink my usage there...
>
> > Though if you are using a libgpiod function to perform the wait you are
> > still stuck, as going by the documentation you have to prevent other
> > access while you are waiting....
>
> > So you have to not use a libgpiod function and wait by poll()ing the
> > request fd.
> > At that point you may as well wait on both requests in the one thread.
> > And then you don't need the mutex as you only have one thread accessing the
> > requests.
>
> I see. So that means waiting on the request fd is not affected by the
> threading contract?

That might technically be a breach of contract, but the fd is
immutable for the lifetime of the request, and I don't see how
that could possibly change, so it is pretty safe.

Cheers,
Kent.


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

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-12  9:55 [libgpiod] - fast writing while waiting for edge events Mathias Dobler
2023-12-12 11:12 ` Bartosz Golaszewski
2023-12-12 13:01   ` Mathias Dobler
2023-12-12 16:02     ` Kent Gibson
2023-12-12 17:06       ` Mathias Dobler
2023-12-13  1:07         ` Kent Gibson
2023-12-13 10:49           ` Mathias Dobler
2023-12-13 11:51             ` Kent Gibson
2023-12-13 12:52               ` Mathias Dobler
2023-12-13 13:12                 ` Kent Gibson [this message]

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=ZXmtvuhehSkt7r9i@rigel \
    --to=warthog618@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mathias.dob@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox