Re: [chromium-dev] [sync/threading] How to post multiple tasks on one sequence in a way that other tasks may have a chance to be run between them?

156 views

Skip to first unread message

nicoles Charles

unread,

Aug 6, 2024, 2:11:09 PM8/6/24

to Chromium-dev, Joe Mason, danielba...@gmail.com, Chromium-dev, scheduler-dev, Adam Rice

On Tuesday, August 6, 2024 at 11:33:55 PM UTC+5:30 Joe Mason wrote:

This sounds like it might be a good candidate for PostJob instead of PostTask: https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/threading_and_tasks.md#Posting-a-Job-to-run-in-parallel

On Tue, Aug 6, 2024, 13:54 Joe Mason <joenot...@google.com> wrote:
Adding scheduler-dev, which might have more suggestions.

On Mon, Aug 5, 2024, 01:40 Adam Rice <ri...@chromium.org> wrote:
The simple way is to have each task post the next one. Something like:

void MergeUpTo1000() {
for (int i = 0; i < 1000 && MergesStillLeftToBeDone(); ++i) {
MergeOne();
}
if (MergesStillLeftToBeDone()) {
PostTask(base::BindOnce(&MergeUpTo1000, weak_ptr_));
}
}

On Sun, 4 Aug 2024 at 03:19, Daniel Baczyński <danielba...@gmail.com> wrote:
Hi

How to post multiple tasks on one sequence in a way that other tasks (not connected with them) may have a chance to be run between them?

Problem:
Having multiple sync-related tasks that should be run in order on a UI/main thread sequence (but other non-related tasks may be allowed between them). Assume there's a lot of them (and time-consuming) so posting them at once would force other UI-related tasks (e.g. mouse event) to wait and lead to browser hang/freeze/stuck for a while. Is there any proper way of allowing UI-related tasks to be run (when they appear) with higher prio and interrupt sync-related tasks for a moment (since they have a lower prio)?

Idea:
Post those sync-related tasks at once but with some tiny delay so that other tasks can have a chance to jump in during these tiny time windows. But that looks like using PostDelayedTask() in a wrong way (it's not delayed because e.g. some retry is scheduled but to make a workaround for chromium threading framework).
One may say: "hey, it's a sequence, just take care of proper posting!" Let's assume we are able to post sync-related tasks at once for now. We would probably need to check in BookmarkModelMerger::Merge() if there are any other tasks on a sequence to allow them to run...

More details:
On bookmarks initial update (sync starts) we have a BookmarkModelMerger::Merge() (UI/main thread) that (depending on number of folders/bookmarks on the account) may last long blocking other UI tasks which leads to a browser freeze for some time.
Inside the merge method we have calls to a BookmarkModel.
BookmarkModel is built and must be run on UI/main thread sequence (not sure why but it's implemented like this and it's not a subject of this discussion).

Idea:
To unburden UI/main thread run BookmarkModelMerger::Merge() on other thread from a thread pool and use PostTaskAndReply() to post BookmarkModel calls on UI/main thread.
Problem: there's a lot of such calls in different places under BookmarkModelMerger::Merge() so creating tasks from them would be probably a nightmare. Also, most time-consuming work is done under BookmarkModel calls.

Note:
It's possible to do some optimizations in BookmarkModel calls (e.g. when notifying observers) but it would just shorten the freeze time and does not change the fact that BookmarkModelMerger::Merge() is a one blob method that blocks UI.

Maybe it would be possible to divide BookmarkModelMerger::Merge() into smaller tasks (containing BookmarkModel calls and other logic). Assuming above we back to the root question: how to run them on the UI/main thread sequence so that other UI tasks are not starved (in a proper way)?
Any other thoughts on the issue?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/de7caa7e-4bad-42e6-8ff7-be08b7ce47f8n%40chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAC_ixdxwF4sAfKj5QLN02r4g56rRRpfOZ19tx0bR7bsGGsvw%3DQ%40mail.gmail.com.

Dominic Farolino

unread,

Aug 12, 2024, 3:51:27 AM8/12/24

to Chromium-dev, Joe Mason, danielba...@gmail.com, Chromium-dev, scheduler-dev, Adam Rice

> Having multiple sync-related tasks that should be run in order on a UI/main thread sequence (but other non-related tasks may be allowed between them).

I like Adam's solution, but if that complicates your architecture at all, then I might just try and target a lower priority task queue for these sync-related tasks. This allows tasks belonging to a higher-priority queue to run in between your lower priority tasks appropriately. See GetUIThreadTaskRunner() which allows you to specify task traits, which includes a priority, which targets the appropriate queue on the thread's sequence manager: https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/browser_thread.h;l=58-68;drc=5203366d4cf174b9331ee33563e0520f10b60828. Also see https://source.chromium.org/chromium/chromium/src/+/main:codelabs/threading_and_scheduling/ for some interesting examples and documentation about all of this.

> Is there any proper way of allowing UI-related tasks to be run (when they appear) with higher prio and interrupt sync-related tasks for a moment (since they have a lower prio)?

This part I don't *think* is achievable with Chromium's threading infrastructure. Since we don't manage our own call stack, I don't think we can preempt a currently-running task on a given thread, run a higher-priority one on that same thread, and then literally restore the state of the "paused" one and resume it, etc. I could be wrong about that, but I don't think I am.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/de7caa7e-4bad-42e6-8ff7-be08b7ce47f8n%40chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

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

Reply all

Reply to author

Forward

0 new messages