[libcamera-devel,v4,0/3] cam: Fix races in event loop and long request processing times

11108 mbox series

Hello,

Using cam to writing requests to (slow) media sometimes lock cam in an
unbreakable loop. At the heart of the problem is that when request
processing was moved from the camera to the main thread subtle races in
the cam event loop implementation where exposed.

The races are easily trigged by having callbacks injected into the even
loop that takes a long time to process. The only callbacks cam currently
injects to the event loop are processing of completed requests. So by
increasing there processing time by writing them to disk the races where
trigged.

This series aims to solve this by integrating the cam event loop closer 
with libevent. As a bonus cam can be made more strict about how it 
operates under the --capture=N mode.

Niklas Söderlund (3):
  cam: event_loop: Rename event_ to base_
  cam: event_loop: Execute events in the libevent loop
  cam: Only queue the exact number of requests asked for

 src/cam/capture.cpp    | 16 +++++++++++---
 src/cam/capture.h      |  2 ++
 src/cam/event_loop.cpp | 49 ++++++++++++++++++++----------------------
 src/cam/event_loop.h   |  8 ++-----
 4 files changed, 40 insertions(+), 35 deletions(-)

Hello Niklas,

I have tested your patch series by making by capturing 75 frames with
two different cameras before and after the patch series. Before I
applied the series my OV13850 received frames until frame 115 and the it
went into the endless loop. The OV4689 received the last frame at frame
88, before going into the endless loop.
After I applied your patch series, the OV13850 received its last frame
at frame number 190 and immediatly stopped the capture. And the OV4689
received its last frame at frame number 115 before stopping the capture.

The output format for the OV13850 was 1920x1920-YUYV8_1_5X8.
And the output format for the OV4689 was 1920x1520-YUYV8_1_5X8.

If you need more information then I can also send you the whole log as a
paste bin.

Greetings,
Sebastian

On 02.02.2021 23:10, Niklas Söderlund wrote:
>Hello,
>
>Using cam to writing requests to (slow) media sometimes lock cam in an

s/to writing/to write/
s/sometimes lock cam/sometimes locks cam/

>unbreakable loop. At the heart of the problem is that when request
>processing was moved from the camera to the main thread subtle races in
>the cam event loop implementation where exposed.

s/where/were/

>
>The races are easily trigged by having callbacks injected into the even
>loop that takes a long time to process. The only callbacks cam currently

s/takes/take

>injects to the event loop are processing of completed requests. So by

s/The only callbacks cam currently injects to the event loop are
processing of completed requests./
The only callback, that cam currently injects into the event loop, is
processing completed requests./
better?

>increasing there processing time by writing them to disk the races where

s/there/their/
s/races where/races were/

>trigged.
>
>This series aims to solve this by integrating the cam event loop closer
>with libevent. As a bonus cam can be made more strict about how it
>operates under the --capture=N mode.
>
>Niklas Söderlund (3):
>  cam: event_loop: Rename event_ to base_
>  cam: event_loop: Execute events in the libevent loop
>  cam: Only queue the exact number of requests asked for
>
> src/cam/capture.cpp    | 16 +++++++++++---
> src/cam/capture.h      |  2 ++
> src/cam/event_loop.cpp | 49 ++++++++++++++++++++----------------------
> src/cam/event_loop.h   |  8 ++-----
> 4 files changed, 40 insertions(+), 35 deletions(-)
>
>-- 
>2.30.0
>
>_______________________________________________
>libcamera-devel mailing list
>libcamera-devel@lists.libcamera.org
>https://lists.libcamera.org/listinfo/libcamera-devel