API to introspect the scope of what thread pool limit set/get API actually does

[itamarst]

There are two things to introspect:

1. Does setting the thread pool limit affect only the current thread, or the whole process?
2. If it affects the whole process, is it setting a per-thread limit for the whole process (what MKL does) or is changing the size of a process-wide global thread pool (OpenBLAS with pthreads)? UPDATE: This part is now in API to introspect semantic meaning of setting a thread pool limit #214.

Use cases for introspection:

• Ensuring documentation on individual controllers is correct.
• A debugging tool for users, both of their current setup, and of potential bugs in threadpoolctl.
• Maybe: Getting a sense of what the current FlexiBLAS backend is actually doing when you tell it to set a limit. Given different OpenBLAS behaviors depending on its threading backend, and given limits of FlexiBLAS introspection, this may need to be done at runtime...

[itamarst]

For introspection item 2, global thread pool vs per-thread thread pool... I can't think of way to introspect this, so far. So might have to drop that.

[ogrisel]

For introspection item 2, global thread pool vs per-thread thread pool... I can't think of way to introspect this, so far. So might have to drop that.

Couldn't we hard code known semantics of various libraries / threading layer combinations and then use tests that spawn subprocesses and dynamically inspect the effective to check that we hardcoded is actually correct?

We can return some "unknown" marker for libraries we have never seen in the past.

[itamarst]

Somewhat, yes. But... you'd need to somehow figure out which Python library is using it and and where it's being used and someplace it'll be used with a suitable number of threads.

Or maybe... For BLAS maybe you can use ctypes to dynamically run a test (and hope it uses all threads). I guess that's fine for documentation use case, adequate for user introspecting/debugging, and probably a bit too much for the FlexiBLAS use case. But that last one isn't high priority.

OpenMP... compile something? You'd need the relevant compiler and libraries available, so it's maybe ok for documentation, and adequate for very motivated developers of libraries, but probably not feasible for most users.

And registered controllers would be out of scope for this issue, at least.

[itamarst]

The above is complex and speculative enough that I'm going to suggest this issue focus just on introspection item 1, and then open a new issue for introspection item 2.

[itamarst]

Draft PR is finding new information, e.g. it's claiming OpenMP on Windows is process-wide scope: https://github.com/joblib/threadpoolctl/actions/runs/28056951772/job/83061664809?pr=213