Open
Bug 1502459
Opened 6 years ago
Updated 2 years ago
give thread pools prioritizable task support
Categories
(Core :: XPCOM, enhancement)
Core
XPCOM
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox65 | --- | affected |
People
(Reporter: froydnj, Unassigned)
References
(Blocks 1 open bug)
Details
Looking at JS's HelperThreads.{h,cpp}, it looks like there's no common "Task" interface (e.g. nsIRunnable or just std::function<void()>); there are separate job queues for every kind of task and therefore there is a priority assigned to each queue (HelperThread::taskSpecs). Our XPCOM thread pools have no notion of task priority, though other thread pools in the tree (e.g. image, network cache) do. So we'd need to grow that capability somehow.
I don't know what the right way to handle this on the XPCOM side is. One option is an API that exposes an nsIEventTarget per-priority-level:
nsIEventTarget targetForPriority(unsigned int priority);
and then the client code could explicitly dispatch to the appropriate nsIEventTarget. I'm not sure we want to expose that sort of API through XPIDL, though.
Another alternative is to have:
void dispatchWithPriority(in nsIRunnable runnable, unsigned int priority);
which wouldn't require cobbling together an nsIEventTarget, and is therefore slightly more efficient?
Either way. the thread pool could be created with some fixed number of priority levels (default: 1), with priority level 0 being the lowest priority, and working our way up from there. I think levels >= the number of priority levels the pool was created with would be clamped at the highest level of priority.
A dynamic number of levels isn't going to be as efficient as a pool with a statically determined number of levels, but I think we're OK with the small amount of inefficiency.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•