Re: [OE-core] [PATCH 3/9] bitbake/runqueue: initialize RunQueueExecute before printdiff rather than after

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2023-12-14 at 14:45 +0100, Alexander Kanavin wrote:
> printdiff needs setscene dependencies and they're available only
> through that object. Previously it was instantianted just after
> running printdiff, this moves the initilization to just prior.
> 
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  bitbake/lib/bb/runqueue.py | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/bitbake/lib/bb/runqueue.py b/bitbake/lib/bb/runqueue.py
> index 864708ee4a5..1f59d18b71a 100644
> --- a/bitbake/lib/bb/runqueue.py
> +++ b/bitbake/lib/bb/runqueue.py
> @@ -1555,6 +1555,11 @@ class RunQueue:
>                                           ('bb.event.HeartbeatEvent',), data=self.cfgData)
>                   self.dm_event_handler_registered = True
>  
> +            self.rqdata.init_progress_reporter.next_stage()
> +            self.start_worker()
> +            self.rqdata.init_progress_reporter.next_stage()
> +            self.rqexe = RunQueueExecute(self)
> +
>              dump = self.cooker.configuration.dump_signatures
>              if dump:
>                  self.rqdata.init_progress_reporter.finish()
> @@ -1566,11 +1571,6 @@ class RunQueue:
>                  self.state = runQueueComplete
>  
>          if self.state is runQueueSceneInit:
> -            self.rqdata.init_progress_reporter.next_stage()
> -            self.start_worker()
> -            self.rqdata.init_progress_reporter.next_stage()
> -            self.rqexe = RunQueueExecute(self)
> -
>              # If we don't have any setscene functions, skip execution
>              if not self.rqdata.runq_setscene_tids:
>                  logger.info('No setscene tasks')

I not entirely happy about this since start_worker() executes processes
and isn't trivial. The code is careful enough to tear them down too at
exit but it is all a bit of a waste of time.

I had wondered if we can create RunQueueExecute() without the workers
but as the code stands, it does poke things into them in a small
isolated section. I think this code flow should be tweaked to stop
RunQueueExecute needing the workers to be started and that would be a
decent cleanup of the code anyway.

I can take a look at that if it helps since I think I've been moving
towards that refactor for a while anyway?

Cheers,

Richard