Closed Bug 1889842 Opened 2 months ago Closed 2 months ago

Build fails with exception from _winapi.WaitForMultipleObjects on Windows on Threadripper machine

Categories

(Core :: DOM: Bindings (WebIDL), defect)

defect

Tracking

()

RESOLVED FIXED
126 Branch
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.

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.

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.)

Assignee: nobody → krosylight
Status: NEW → ASSIGNED
Blocks: mach-busted
Attachment #9395202 - Attachment description: Bug 1889842 - Limit to 4 processes on Windows r=peterv,sergesanspaille → Bug 1889842 - Default to 4 processes on Windows r=peterv,sergesanspaille
Pushed by krosylight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/24f2844f786e
Default to 4 processes on Windows r=sergesanspaille
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 126 Branch
Flags: needinfo?(sguelton)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: