[libcamera-devel] [PATCH v3 09/17] py: Switch to non-blocking eventfd

[Laurent Pinchart]

On Thu, Aug 18, 2022 at 06:21:51PM +0300, Tomi Valkeinen wrote:
> On 18/08/2022 18:02, Jacopo Mondi wrote:
> >> On 18/08/2022 17:29, Jacopo Mondi wrote:
> >>> On Fri, Jul 01, 2022 at 11:45:13AM +0300, Tomi Valkeinen wrote:
> >>>> Blocking wait can be easily implemented on top in Python, so rather than
> >>>> supporting only blocking reads, or supporting both non-blocking and
> >>>> blocking reads, let's support only non-blocking reads.
> >>>>
> >>>
> >>> I'm not sure why it is better to ask application to do so on out
> >>> behalf, having to expose the camera manager eventfd...
> >>
> >> We want to expose the fd anyway. Most, or at least all serious uses will
> >> need the fd to wait for the events. That's how it is even before this
> >> series.
> >>
> >> The point of this change is that instead of offering a function to get the
> >> ready events which blocks if there are no events, we offer a function which
> >> never blocks.
> >>
> >> With this change the users can either just call the function whenever to see
> >> if there are events, or they can wait for the events with the fd. Previously
> >> this was not possible.
> > 
> > I would have expected a non-blocking "eventReady()" and a blocking
> > implementation inside the python wrapper instead of having apps to
> > instrument a selector. Maybe that's typical for Python ?
> 
> There are, of course, many ways to implement this. This was discussed, 
> and if I recall right, in my previous versions (and some I didn't send) 
> I was going back and forth between different ways to manage this. If I 
> recall right, Laurent was (strongly?) of the opinion that blocking mode 
> is not needed by the helpers. I'm kind of in the middle, I guess. It's 
> easy to implement on top, though.

That matches my recollection of the discussions :-)

-- 
Regards,

Laurent Pinchart