Re: [Intent to ship] //base/task Jobs API

[Gabriel Charette]

On Wed, Oct 2, 2019 at 1:18 PM Gabriel Charette <g...@chromium.org> wrote:

Hello everyone,

In an effort to improve transparency and awareness of ongoing development we will try to provide chromium-dev@ with intent-to-implement/intent-to-ship on core //base APIs. We encourage everyone to do this for broad reaching changes. A formal process will be announced later when we've fully wrapped our head around the desired approach.

As mentioned in our last PSA, we are about to ship the Jobs API.

This API is intended for power users such as v8 that need efficient mass parallelism. It will allow scheduling a single base::RepeatingCallback through //base/task/post_job.h and request that base::ThreadPool workers invoke it concurrently. This avoids degenerate cases which occur when many components post num_cores tasks and the scheduler lacks context. In fact, v8 has custom logic in some scenarios today to suboptimally post num_cores/2 tasks (e.g. when compiling) to make sure it doesn't flood all workers should a GC (high priority garbage collection) kick in... The Jobs API solves this by bringing yield semantics. So all jobs can utilize all cores and yield if a more important task/job needs a worker.

This API also avoids having to invoke BindOnce for every task (twice in fact because of the //gin layer) which was also an efficiency problem in some high performance cases (e.g. javascript compilation). v8 would batch multiple work items in each task to try to work around that (but that brings us back to inability to yield quickly and further motivates yield semantics).

Cheers,

Gab

[Gabriel Charette]