Open Bug 1502459 Opened 6 years ago Updated 2 years ago

give thread pools prioritizable task support

Categories

(Core :: XPCOM, enhancement)

enhancement

Tracking

()

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.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.