Skip to content

FIX Don't restore the limits if setting them was a no-op - #300

Open
itamarst wants to merge 15 commits into
joblib:masterfrom
itamarst:299-overlapping-restores
Open

itamarst wants to merge 15 commits into
joblib:masterfrom
itamarst:299-overlapping-restores

Conversation

@itamarst

@itamarst itamarst commented Nov 5, 2026 •

Copy link
Copy Markdown
Contributor

@itamarst
itamarst marked this pull request as ready for review November 5, 2026 20:38
@itamarst

itamarst commented Nov 5, 2026

Copy link
Copy Markdown
Contributor Author

Plausibly there's a second half missing, where the top-level restore of threadpoolctl, the one where it relinquishes control, should always be to the original level of the process, because when it grabs the original level it might grab the wrong one as a race condition.

@itamarst

itamarst commented Nov 5, 2026

Copy link
Copy Markdown
Contributor Author

Or, another way of saying it, if thread A stores values to restore to at a time when thread B is the controlling thread, the restore value is wrong, and should instead be "all cores" (zero? or a level stored at startup). Will do that or equivalent tomorrow.

@itamarst

itamarst commented Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

The above is a real race condition (I have implemented a test and fix) but it is still not enough to fix the joblib race condition reproducer!

@itamarst

itamarst commented Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

Will continue trying to figure out the joblib race condition next week.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OpenBLAS controlling thread logic needs to be smarter when thre are overlapping set/restore pairs in different threads

1 participant