forked from mirrors/gecko-dev
38dbc8112e
The original intention of adding NS_DISPATCH_AT_END always when on the same pool was to reduce the risk of spinning up unneeded threads. Bug 1891664 introduced two changes that make this now unwanted: - we always wait for the dispatching thread to pick up the event - we give threads a grace timeout before shutting them down So before bug 1891664 landed, this flag would just have influenced if we create a new thread, but if there was an idle thread, the event would just process immediately and in parallel without any latency. Now the event will wait for the dispatching thread to become idle if NS_DISPATCH_AT_END is set, which might increase the latency if we are not at the end of the dispatching event as we are instead in the case of TaskQueue dispatches. What's more, the grace timeout reduces the risk of noise from frequent thread creation and destruction, such that creating a new thread when there is load we can immediately serve is actually best for latency. Differential Revision: https://phabricator.services.mozilla.com/D212399 |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| components | ||
| docs | ||
| ds | ||
| geckoprocesstypes_generator | ||
| glue | ||
| idl-parser | ||
| io | ||
| reflect | ||
| rust | ||
| string | ||
| system | ||
| tests | ||
| threads | ||
| windbgdlg | ||
| xpidl | ||
| metrics.yaml | ||
| moz.build | ||