Re: [libgpiod v2][PATCH v2 5/5] bindings: python: add the implementation for v2 API

[Kent Gibson <warthog618@xxxxxxxxx>]

On Fri, Jul 01, 2022 at 10:18:00AM +0200, Bartosz Golaszewski wrote:
> On Fri, Jul 1, 2022 at 10:02 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >

....

> > > > Timedelta constructor is much more explicit than a float IMO. How
> > > > about a compromise and taking both (mutually exclusive)?
> > > > timeout=datettime.timedelta(seconds=1) == timeout_sec=float(1.0)?
> > > >
> > >
> > > Maybe, but float seconds seems to be the way they do it.
> > > If you insist on both then just the one timeout parameter and work the
> > > type out on the fly. (it's Python, so dynamic typing...)
> > >
> >
> > Same issue for chip.wait_info_event(), btw.
> > Still working through a full review - but it'll probably take a while.
> >
> > Wrt the wait, does the C API have a blocking wait, or do you have to
> > poll() the fd?
> >
> 
> Blocking wait is simply reading the event without checking if an event
> is there to be read. select() (the system call) waits indefinitely if
> the timeval struct is NULL, ppoll() behaves the same for a NULL
> timespec, poll() does the same for a negative timeout (which is an
> int). We take an uint64_t so we can't do it. Either we need to switch
> to int64_t and interpret a negative value as indefinite wait or just
> not do it at all and tell users to just call the (blocking)
> read_edge_event().
> 

If you want to support timeout=NONE for the Python API then you will
have to change the C API to int64_t to support negative for blocking.
Having the Python req.wait_edge_event() switch to calling the C
read_edge_event() for that case isn't an option.

Cheers,
Kent.