Build fails with exception from _winapi.WaitForMultipleObjects on Windows on Threadripper machine
Categories
(Core :: DOM: Bindings (WebIDL), defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox124 | --- | unaffected |
firefox125 | --- | unaffected |
firefox126 | --- | fixed |
People
(Reporter: saschanaz, Assigned: saschanaz)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(1 file)
This is a known Python issue; the default process count of multiprocess.Pool MUST NOT be used as it's faulty: https://github.com/python/cpython/issues/89240
The caller need to cap it to 61 on Windows.
Comment 1•2 months ago
|
||
Set release status flags based on info from the regressing bug 1886167
:sergesanspaille, since you are the author of the regressor, bug 1886167, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Assignee | ||
Comment 2•2 months ago
|
||
Other than the faulty Python API issue, forking 60 processes is quite expensive on Windows and takes 40sec on my Threadripper machine. This patch limits it to 4 processes because any more than that actually makes things slower.
(Giving 4 processes causes no difference from not spawning extra process at all, but for now I'm not disabling parallel pool here.)
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Pushed by krosylight@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/24f2844f786e Default to 4 processes on Windows r=sergesanspaille
Comment 4•2 months ago
|
||
bugherder |
Updated•2 months ago
|
Description
•