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

Message ID 20210119123110.2976971-1-niklas.soderlund@ragnatech.se
Headers show
Series
  • cam: Fix races in event loop and long request processing times
Related show

Message

Niklas Söderlund Jan. 19, 2021, 12:31 p.m. UTC
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 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
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(-)

Comments

Sebastian Fricke Jan. 19, 2021, 5:55 p.m. UTC | #1
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@lists.libcamera.org
>https://lists.libcamera.org/listinfo/libcamera-devel