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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Fri, Jul 1, 2022 at 10:52 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Fri, Jul 01, 2022 at 10:32:30AM +0200, Bartosz Golaszewski wrote:
> > On Fri, Jul 1, 2022 at 10:18 AM Bartosz Golaszewski <brgl@xxxxxxxx> 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().
> > >
> > > Bart
> > >
> >
> > I'm still on the fence about using timespec. It seems that the more
> > recent linux interfaces avoid timespec and timeval altogether due to
> > the year 2038 problem and the subsequent change in the struct layout.
> > On the other hand the timeouts are unlikely to be set to years. :)
> >
> > What do you think?
> >
>
> I prefer not using timespecs.  I prefer the int64 microseconds/nanoseconds
> or float seconds approaches.
> Especially for the time scales we are concerned with.
> I only use timespecs where existing APIs such as ppoll() require it.
>
> For the C API I'd go with int64 nsec, for Python float secs.
> (though as already covered - with Python you could accept float
> secs, int nsec, or a timedelta all in the one parameter)
>

Makes sense, I'll prepare a patch.