mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-28 07:13:20 +00:00
1b72ad9705
We need some way of differentiating "tasks that just consume CPU" vs. "tasks that block on some external resource" like reading from a socket or a file. If we didn't have this, we'd either a) have a thread pool sized for the number of CPUs where having all the threads blocked on I/O--and therefore no new tasks are able to run--or b) have a thread pool that tries to increase the number of working threads based on the number of submitted tasks and winds up having too many tasks running with not enough CPUs to run them on. This flag enables us to theoretically get the best of both worlds: we can set aside `~#CPUs` threads for CPU-intensive work, and `$SOME_NUMBER` threads for I/O work. The latter number can be adjusted up if the I/O load on the system is particularly heavy. The implementation strategy of this patch is to use two separate thread pools for the two different kinds of work. It's entirely possible that we'll want to use a single thread pool to coordinate thread create between the two kinds of work, or even migrate threads from one kind of work to the other, but such improvements can be future work. The focus right now is providing the rest of Gecko with a common funnel to put tasks into, and we can adjust what's at the end of the funnel at a later point. Differential Revision: https://phabricator.services.mozilla.com/D51708 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| components | ||
| doc | ||
| ds | ||
| glue | ||
| idl-parser | ||
| io | ||
| libxpt/xptcall | ||
| reflect | ||
| rust | ||
| string | ||
| system | ||
| tests | ||
| threads | ||
| windbgdlg | ||
| xpidl | ||
| moz.build | ||
| xpcom-config.h.in | ||
| xpcom-private.h.in | ||