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

[Tomi Valkeinen]

On 18/08/2022 18:02, Jacopo Mondi wrote:
>> On 18/08/2022 17:29, Jacopo Mondi wrote:
>>> Hi Tomi
>>>
>>> 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.

  Tomi