[libcamera-devel] [PATCH 0/2] cam: Fix races in event loop and long request processing times

[Sebastian Fricke]

Hey Niklas,

Thank you for the patch!

Just a few typo corrections here.

On 19.01.2021 13:31, Niklas Söderlund wrote:
>Hello,
>
>Using cam to writing requests to (slow) media sometimes lock cam in an

s/cam to writing requests/cam to write requests/
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

s/The races/Those races/

>loop that takes a long time to process. The only callbacks cam currently

s/that takes/that take/
s/The only callbacks cam/The only callbacks that cam/

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

s/are processing of/are processing/

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

s/there processing time/the processing time/

>trigged.
>
>This series fixes two different issues found when debugging this. Patch
>1/2 solves a design issue in the event loop implementation where the
>callback queue can be flooded which prevents termination of the loop.
>While patch 2/2 solves a cam design issue where the --capture=N behavior
>of only capturing N requests where broken but hidden by the problem in

s/where broken/was broken/

>patch 1/2.
>
>Niklas Söderlund (2):
>  cam: event_loop: Stop queuing calls when the event loop are exiting
>  cam: Fix capturing an precis number of requests
>
> src/cam/capture.cpp    | 12 ++++++------
> src/cam/event_loop.cpp |  2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
>-- 
>2.30.0
>
>_______________________________________________
>libcamera-devel mailing list
>libcamera-devel at lists.libcamera.org
>https://lists.libcamera.org/listinfo/libcamera-devel