Posting renderer tasks from content/ to appropriate task queue.

4 views
Skip to first unread message

Alexander Timin

unread,
Dec 21, 2016, 2:57:41 PM12/21/16
to platform-architecture-dev, scheduler-dev, Sami Kyostila, Kentaro Hara, task-sche...@chromium.org
Hi

As a part of per-frame scheduler effort I put together some initial thoughts about posting tasks from content/ to appropriate task queues.

Feedback is welcome, I'm particularly interested in opinions of Lucky Luke devs.

-
Alexander

Elliott Sprehn

unread,
Dec 21, 2016, 3:04:30 PM12/21/16
to Alexander Timin, task-sche...@chromium.org, scheduler-dev, Kentaro Hara, platform-architecture-dev, Sami Kyostila
It sounds like a reasonable plan, though I hope we can focus on getting content/renderer trimmed down as well. The amount of code outside blink posting tasks should be extremely minimal. Let's start with the smallest API possible and go from there since folks should be Onion Souping features instead of using new Web* APIs.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALHg4nndNoBKQ2ZCbUfGfR4LW91bvpxDSpFjweGujUaO%3Dv_Pww%40mail.gmail.com.

Gabriel Charette

unread,
Dec 21, 2016, 3:12:49 PM12/21/16
to Elliott Sprehn, Alexander Timin, task-sche...@chromium.org, scheduler-dev, Kentaro Hara, platform-architecture-dev, Sami Kyostila
Funneling into 3 TaskRunners reminisces issues that TaskScheduler is aiming to solve with dedicated BrowserThreads (i.e. many unrelated tasks sequenced together).

I understand that Blink is single-threaded and that everything needs to ultimately funnel down to one thread but it'd be great if sequences were merely composed of other sequences (i.e. you'd have the master 3 sequences funneling to the main thread and each one of those would be a series of independent sequences that can also be ordered as fits within self).

FWIW, this is how GCD (Grand Central Dispatch) works. TaskScheduler is thinking of potentially supporting this very use case for BrowserThread::UI, BrowserThread::IO, and Blink main thread next year.

On Wed, Dec 21, 2016 at 3:04 PM Elliott Sprehn <esp...@chromium.org> wrote:
It sounds like a reasonable plan, though I hope we can focus on getting content/renderer trimmed down as well. The amount of code outside blink posting tasks should be extremely minimal. Let's start with the smallest API possible and go from there since folks should be Onion Souping features instead of using new Web* APIs.

On Dec 21, 2016 11:57 AM, "Alexander Timin" <alt...@chromium.org> wrote:
Hi

As a part of per-frame scheduler effort I put together some initial thoughts about posting tasks from content/ to appropriate task queues.

Feedback is welcome, I'm particularly interested in opinions of Lucky Luke devs.

-
Alexander

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALHg4nndNoBKQ2ZCbUfGfR4LW91bvpxDSpFjweGujUaO%3Dv_Pww%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAO9Q3iKr9BOwwfZi2oxdsFTZSd6O%2BHEVH5U-CuNY3r-j6OH6eg%40mail.gmail.com.

Gabriel Charette

unread,
Dec 21, 2016, 3:13:23 PM12/21/16
to Gabriel Charette, Elliott Sprehn, Alexander Timin, task-sche...@chromium.org, scheduler-dev, Kentaro Hara, platform-architecture-dev, Sami Kyostila
PS: what's Onion Soup :)?

Daniel Cheng

unread,
Dec 21, 2016, 3:34:50 PM12/21/16
to Gabriel Charette, Elliott Sprehn, Alexander Timin, task-sche...@chromium.org, scheduler-dev, Kentaro Hara, platform-architecture-dev, Sami Kyostila
Elliot can explain this better, but the basic idea is to reorganize Blink's layering so implementing a web API doesn't involve plumbing something from //third_party/WebKit/Source/core to //third_party/WebKit/public to //content/renderer to //content/browser. Historically, we needed to do this because we didn't want to expose IPC directly to Blink.

However, we're now using Mojo interfaces to define an API layer between Blink and the embedder (content). This lets us move the IPC boundary into the Blink public API itself rather than having to go through //content/renderer. This should allow a lot (hopefully all, but that's unclear at the moment) of //content/renderer to moved completely into Blink. The net effect is we can simplify the Blink public API, reduce the number of plumbing layers, and get rid of things like WebString/WebURL.

Daniel

You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-...@chromium.org.
To post to this group, send email to task-sche...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/task-scheduler-dev/CAJTZ7LJ2S5qmLFDT3U793DeAiGzEntVWUkTjJRgQFEcUg23sDg%40mail.gmail.com.

Kentaro Hara

unread,
Dec 21, 2016, 8:14:44 PM12/21/16
to Daniel Cheng, Gabriel Charette, Elliott Sprehn, Alexander Timin, task-sche...@chromium.org, scheduler-dev, platform-architecture-dev, Sami Kyostila
The migration plan looks good to me.

Just curious: On the Blink side, almost all tasks are expected to be associated with frames and posted to the per-frame scheduler. Only a few tasks are posted to the renderer-wide scheduler. On the content/ side, how much of the tasks will be posted to the renderer-wide scheduler? Are there many tasks that cannot be associated with frames for some reason?




On Thu, Dec 22, 2016 at 5:34 AM, Daniel Cheng <dch...@chromium.org> wrote:
Elliot can explain this better, but the basic idea is to reorganize Blink's layering so implementing a web API doesn't involve plumbing something from //third_party/WebKit/Source/core to //third_party/WebKit/public to //content/renderer to //content/browser. Historically, we needed to do this because we didn't want to expose IPC directly to Blink.

However, we're now using Mojo interfaces to define an API layer between Blink and the embedder (content). This lets us move the IPC boundary into the Blink public API itself rather than having to go through //content/renderer. This should allow a lot (hopefully all, but that's unclear at the moment) of //content/renderer to moved completely into Blink. The net effect is we can simplify the Blink public API, reduce the number of plumbing layers, and get rid of things like WebString/WebURL.

Daniel

On Wed, Dec 21, 2016 at 12:13 PM Gabriel Charette <g...@chromium.org> wrote:
PS: what's Onion Soup :)?

On Wed, Dec 21, 2016 at 3:12 PM Gabriel Charette <g...@chromium.org> wrote:
Funneling into 3 TaskRunners reminisces issues that TaskScheduler is aiming to solve with dedicated BrowserThreads (i.e. many unrelated tasks sequenced together).

I understand that Blink is single-threaded and that everything needs to ultimately funnel down to one thread but it'd be great if sequences were merely composed of other sequences (i.e. you'd have the master 3 sequences funneling to the main thread and each one of those would be a series of independent sequences that can also be ordered as fits within self).

FWIW, this is how GCD (Grand Central Dispatch) works. TaskScheduler is thinking of potentially supporting this very use case for BrowserThread::UI, BrowserThread::IO, and Blink main thread next year.

On Wed, Dec 21, 2016 at 3:04 PM Elliott Sprehn <esp...@chromium.org> wrote:
It sounds like a reasonable plan, though I hope we can focus on getting content/renderer trimmed down as well. The amount of code outside blink posting tasks should be extremely minimal. Let's start with the smallest API possible and go from there since folks should be Onion Souping features instead of using new Web* APIs.

On Dec 21, 2016 11:57 AM, "Alexander Timin" <alt...@chromium.org> wrote:
Hi

As a part of per-frame scheduler effort I put together some initial thoughts about posting tasks from content/ to appropriate task queues.

Feedback is welcome, I'm particularly interested in opinions of Lucky Luke devs.

-
Alexander

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-dev+unsub...@chromium.org.
To post to this group, send email to task-scheduler-dev@chromium.org.



--
Kentaro Hara, Tokyo, Japan

Sami Kyostila

unread,
Dec 22, 2016, 6:30:00 AM12/22/16
to Kentaro Hara, Daniel Cheng, Gabriel Charette, Elliott Sprehn, Alexander Timin, task-sche...@chromium.org, scheduler-dev, platform-architecture-dev
I think we'll need to investigate a bit more to figure out the exact split, but for example v8 posts a bunch of tasks through gin which appear to be per-isolate, i.e., not neatly mappable to a single frame.

- Sami

to 22. jouluk. 2016 klo 1.14 Kentaro Hara <har...@chromium.org> kirjoitti:
The migration plan looks good to me.

Just curious: On the Blink side, almost all tasks are expected to be associated with frames and posted to the per-frame scheduler. Only a few tasks are posted to the renderer-wide scheduler. On the content/ side, how much of the tasks will be posted to the renderer-wide scheduler? Are there many tasks that cannot be associated with frames for some reason?



On Thu, Dec 22, 2016 at 5:34 AM, Daniel Cheng <dch...@chromium.org> wrote:
Elliot can explain this better, but the basic idea is to reorganize Blink's layering so implementing a web API doesn't involve plumbing something from //third_party/WebKit/Source/core to //third_party/WebKit/public to //content/renderer to //content/browser. Historically, we needed to do this because we didn't want to expose IPC directly to Blink.

However, we're now using Mojo interfaces to define an API layer between Blink and the embedder (content). This lets us move the IPC boundary into the Blink public API itself rather than having to go through //content/renderer. This should allow a lot (hopefully all, but that's unclear at the moment) of //content/renderer to moved completely into Blink. The net effect is we can simplify the Blink public API, reduce the number of plumbing layers, and get rid of things like WebString/WebURL.

Daniel

On Wed, Dec 21, 2016 at 12:13 PM Gabriel Charette <g...@chromium.org> wrote:
PS: what's Onion Soup :)?

On Wed, Dec 21, 2016 at 3:12 PM Gabriel Charette <g...@chromium.org> wrote:
Funneling into 3 TaskRunners reminisces issues that TaskScheduler is aiming to solve with dedicated BrowserThreads (i.e. many unrelated tasks sequenced together).

I understand that Blink is single-threaded and that everything needs to ultimately funnel down to one thread but it'd be great if sequences were merely composed of other sequences (i.e. you'd have the master 3 sequences funneling to the main thread and each one of those would be a series of independent sequences that can also be ordered as fits within self).

FWIW, this is how GCD (Grand Central Dispatch) works. TaskScheduler is thinking of potentially supporting this very use case for BrowserThread::UI, BrowserThread::IO, and Blink main thread next year.

On Wed, Dec 21, 2016 at 3:04 PM Elliott Sprehn <esp...@chromium.org> wrote:
It sounds like a reasonable plan, though I hope we can focus on getting content/renderer trimmed down as well. The amount of code outside blink posting tasks should be extremely minimal. Let's start with the smallest API possible and go from there since folks should be Onion Souping features instead of using new Web* APIs.

On Dec 21, 2016 11:57 AM, "Alexander Timin" <alt...@chromium.org> wrote:
Hi

As a part of per-frame scheduler effort I put together some initial thoughts about posting tasks from content/ to appropriate task queues.

Feedback is welcome, I'm particularly interested in opinions of Lucky Luke devs.

-
Alexander

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-...@chromium.org.
To post to this group, send email to task-sche...@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-...@chromium.org.
To post to this group, send email to task-sche...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/task-scheduler-dev/CABg10jym9pWO-xg9SkyKx1oT3HX2hMD0F_-si%3DwUdHzUZqSf8g%40mail.gmail.com.

Alexander Timin

unread,
Dec 22, 2016, 11:46:42 AM12/22/16
to Kentaro Hara, Elliott Sprehn, Daniel Cheng, Sami Kyostila, Gabriel Charette, task-sche...@chromium.org, scheduler-dev, platform-architecture-dev
I plan to go through these usages in renderer/content and create a spreadsheet and annotate them (probably in January). This way we will get an approximate answer to the per-frame vs renderer-wide question.

But yes, it seems that there will be a number of renderer-wide tasks.

Alexander

- Sami

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-dev+unsub...@chromium.org.
To post to this group, send email to task-scheduler-dev@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-dev+unsub...@chromium.org.
To post to this group, send email to task-scheduler-dev@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.

To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAPuLczuNr-iQaTjmjuNsNGRGpOiFo_6af%3DR%3DcJWWmYLAYcBVnQ%40mail.gmail.com.

Kentaro Hara

unread,
Dec 22, 2016, 12:34:54 PM12/22/16
to Alexander Timin, Elliott Sprehn, Daniel Cheng, Sami Kyostila, Gabriel Charette, task-sche...@chromium.org, scheduler-dev, platform-architecture-dev
On Fri, Dec 23, 2016 at 1:46 AM, Alexander Timin <alt...@google.com> wrote:
I plan to go through these usages in renderer/content and create a spreadsheet and annotate them (probably in January). This way we will get an approximate answer to the per-frame vs renderer-wide question.

But yes, it seems that there will be a number of renderer-wide tasks.

(Just to clarify: I was just curious if there're many renderer-wise tasks in content/ -- I'm not intending to block you on the investigation :-)


 
Alexander

- Sami

To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsubsc...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAO9Q3iKr9BOwwfZi2oxdsFTZSd6O%2BHEVH5U-CuNY3r-j6OH6eg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to task-sche...@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "task-scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to task-scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to task-sche...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-dev+unsubscribe@chromium.org.
To post to this group, send email to schedu...@chromium.org.
Reply all
Reply to author
Forward
0 new messages