Skip to content

DOC clarify OpenMP runtime conflicts on Windows #301

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Yushu-Li wants to merge 1 commit into
base: master
Choose a base branch
from
Open

DOC clarify OpenMP runtime conflicts on Windows #301

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 11 additions & 13 deletions multiple_openmp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,19 +31,17 @@ package compiled with GCC, the most widely used C compiler on that platform).

## Incompatibility between Intel OpenMP and LLVM OpenMP

The only unrecoverable incompatibility we encountered happens when loading a
mix of compiled extensions linked with **`libomp` (LLVM/Clang) and `libiomp`
(ICC), on Linux and macOS**, manifested by crashes or deadlocks. It can happen
even with the simplest OpenMP calls like getting the maximum number of threads
that will be used in a subsequent parallel region. A possible explanation is that
`libomp` is actually a fork of `libiomp` causing name colliding for instance.
Using `threadpoolctl` may crash your program in such a setting.

**Fortunately this problem is very rare**: at the time of writing, all major
binary distributions of Python packages for Linux use either GCC or ICC to
build the Python scientific packages. Therefore this problem would only happen
if some packagers decide to start shipping Python packages built with
LLVM/Clang instead of GCC (this is the case for instance with conda's default channel).
Loading compiled extensions linked with both **`libomp` (LLVM/Clang) and
`libiomp` (Intel)** can cause crashes or deadlocks. Even querying the maximum
number of threads for a subsequent parallel region can trigger the problem.
The incompatibility has been observed on Linux and macOS, and a similar
deadlock was [reported on Windows](https://github.com/scipy/scipy/issues/23989).

@ogrisel ogrisel Nov 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this deadlock was discovered on Windows, I think the Linux-only condition to display the warning in _warn_if_incompatible_openmp should be removed and we should warn on all operating systems.

Do you agree @lucascolley?

@Yushu-Li would you be interested in trying to reproduce the failure on macOS and Windows to confirm? If so we should update the code in _warn_if_incompatible_openmp and update this paragraph accordingly.

@lucascolley lucascolley Nov 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this deadlock was discovered on Windows, I think the Linux-only condition to display the warning in _warn_if_incompatible_openmp should be removed and we should warn on all operating systems.

Do you agree @lucascolley?

yes, re-reading the linked issue, I think that was my thought at the time


The risk depends on how the packages are built. For example, some Windows
builds provide a `libiomp` that forwards to `libomp`, so both filenames can
appear without two independent runtimes being loaded. `threadpoolctl` currently
warns when it detects both library prefixes on Linux. On other platforms, the
absence of this warning does not rule out a runtime conflict.

## Workarounds for Intel OpenMP and LLVM OpenMP case

Expand Down
Loading