Re: [libgpiod] Python bindings don't allow to wait on events indefinitely

[Nicolas Frattaroli <frattaroli.nicolas@xxxxxxxxx>]

On Freitag, 19. Mai 2023 07:17:27 CEST Kent Gibson wrote:
> On Thu, May 11, 2023 at 10:28:34PM +0200, Nicolas Frattaroli wrote:
> > Hello,
> > 
> > in libgpiod 1.6.x, Line.event_wait's codepath had no path where ts
> > as passed to ppoll could ever be NULL. This means waiting indefinitely
> > was impossible.
> > 
> > I thought hey, maybe the new Python bindings in libgpiod 2.x fixed this,
> > but no, it has made it worse by explicitly setting timeout to 0 seconds
> > if it's None[1]. Obviously, this behaviour can't be changed now, because
> > people depend on this API to return immediately now with None as the
> > parameter, and changing it to wait indefinitely would no doubt break
> > actual programs.
> > 
> > So I'm left wondering if there's a particular reason users of these
> > bindings shouldn't wait on events indefinitely or if that same mistake
> > was just made twice in a row.
> > 
> > Is there some way the API could be enhanced to support waiting for
> > events indefinitely without having to slap a While True with
> > an arbitrarily high timeout around every single invocation?
> > 

Hello Kent,
 
> That does sound like a bug to me, but the rest of your mail isn't worth
> responding to.

I'm not quite sure what you mean. Was my tone this off? I apologise if
you took my displeasure with libgpiod's bindings as a personal attack,
it wasn't intended as such.

> A more productive approach could be to submit a patch that describes the
> problem and suggests a fix, say:
> 
>  def poll_fd(fd: int, timeout: Optional[Union[timedelta, float]] = None) -> bool:
> -    if timeout is None:
> -        timeout = 0.0
> -
> 
> and see where that goes.

That would go nowhere, as this makes the API behave differently for current
users calling the function without an argument, as I've mentioned.

One solution would be to pass float("inf") and then check for that, this
wouldn't break the API, merely extend it, but I'm not sure how good of
an idea that is to do if someone uses an older libgpiod that doesn't
have an explicit check for inf. I don't even know what passing inf does
right now, but it's probably worth looking into.

> to submit a patch

Move the project back to a git forge and I will.

> Cheers,
> Kent.

Regards,
Nicolas Frattaroli