Blink task types are confusing

[Daniel Cheng]

Hi all,

I was reviewing a CL today, and I saw a CL that was using TaskType::kMiscPlatformAPI as the task runner for a Mojo binding. However, we also have TaskType::kInternalIPC and TaskType::kMainThreadTaskQueueIPC. So I'm trying to understand the difference...

1. What is the rule for which task runner to use for IPC? I'm told that if a Mojo API is used to implement a Web API, the right task runner is actually kMiscPlatformAPI. This seems confusing to me: there are probably interfaces that implement both non-web API and web API functionality. This would imply they have to be split, purely because of the task type. That doesn't seem great to me. Can we just use kInternalIPC for all of these?
2. Are the various kMainThreadQueue task types internal implementation details? The header doesn't make this clear.

Daniel

[Hajime Hoshi]

For 2., yes, kMainThread* (and other k*Thread*) is an implementation detail, and they are used for UMA annotations of per-thread task runners. Then there should not be actual use cases to specify such task types explicitly. I'll try to refine the comment. Thanks.

 

Daniel

--
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/CAF3XrKpeYJJW1zWAjeELg-WUwZn7ESw4AzEK9DSJnetW%2BjFW1Q%40mail.gmail.com.

[Kentaro Hara]

I agree with Daniel -- the task types are confusing.

(We discussed this multiple times but) my preference is still to separate "task types" from "task annotations (for profiling)". "Task types" should be limited to speced task types and a couple of internal ones (that need different scheduling policies). Having many kInternalXXX makes things confusing. Separately, we can add arbitrary annotations to individual tasks for profiling purposes.

> This seems confusing to me: there are probably interfaces that implement both non-web API and web API functionality. This would imply they have to be split, purely because of the task type. That doesn't seem great to me. Can we just use kInternalIPC for all of these?

In common cases, using speced task types for non-speced tasks doesn't cause any issue. So, in common cases you don't need to split the interfaces.

The guideline is:

1) If the task is used for speced tasks (and probably non-speced tasks), use the speced task types.

2) Otherwise, use kInternalXXX task types depending on the scheduling policy you want.

I'd suggest merging kInternalIPC (and many other kInternalXXXs) with kInternalDefault. If we want to distinguish the tasks, we should use task annotations, not task types.

My 2 cents :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CALKePfz9RUFquNULqV8ROpDjcOBTdXTDZRj1gAkAwpt4UdDDyw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Kentaro Hara]

(Let me revive this thread.)

I was looking at this CL and noticed that people are confused with kInternalIPC vs. kInternalDefault again.

Alexander: Do you have any thoughts on this? :)

[Alexander Timin]

The intention here is that kInternalIPC will be used for the tasks which are associated with legacy IPC channel (associated interfaces) and have to run in order with them and kInternalDefault for everything else which doesn't have this requirement.

I'll upload a patch to rename this and hopefully this will make things clearer for now. As for the larger scheme of things, I'll try to think about this more and try to do something when I have a bit more time.

[Alexander Timin]

Uploaded a patch to rename kInternalIPC: https://chromium-review.googlesource.com/c/chromium/src/+/1624921/

Bikeshedding about naming is welcome, here or in the codereview :)

[Kentaro Hara]

Thanks Alexander!

The renaming is nice but I'm not sure if the fundamental problem is resolved -- there are too many task types and it's confusing developers.

As I mentioned in the previous email, I think we should consider separating "task types" from "task annotations".

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CALHg4nkSx0wPZu21_oBuFBA_E5EpF__2fyk8D9ZrMbgWpikm5g%40mail.gmail.com.

[Alexander Timin]

On Wed, 22 May 2019 at 19:05, Kentaro Hara <har...@chromium.org> wrote:

Thanks Alexander!

The renaming is nice but I'm not sure if the fundamental problem is resolved -- there are too many task types and it's confusing developers.

As I mentioned in the previous email, I think we should consider separating "task types" from "task annotations".

Yes, I fully agree. I have some thoughts on how we can make this better (short answer: traits!), but I definitely won't be able to get to it before late June with late July-August being a realistic timeline. 

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/CABg10jySr4HErmnDqA%2B4BdMfgVYwCkqwan%2BjDsi4Wo4ihFyweg%40mail.gmail.com.

[Alexander Timin]

A quick update on this: August turned out to be unrealistic timeline, but kInternalIPC task type is gone now.

I'll continue looking into how things can be simplified further, but no estimates on it this time around :)

[Kentaro Hara]

\o/

On Fri, Nov 22, 2019 at 1:21 PM Alexander Timin <alt...@chromium.org> wrote:

A quick update on this: August turned out to be unrealistic timeline, but kInternalIPC task type is gone now.

I'll continue looking into how things can be simplified further, but no estimates on it this time around :)

[Daniel Cheng]

Thanks for cleaning this up!

Daniel