Interactive threads in Julia v1.9.0-beta do not give expected results

[simsurace]

Isn't this behavior contradicting the docs?

$ julia +beta -t 1,1

julia> fetch(Threads.@spawn :interactive Threads.threadpool())
:default # expecting :interactive

julia> Threads.nthreads()
1 # expecting 2

[vtjnash]

Threads.nthreads is soft-deprecated, for this and other reasons. Don't use it anymore.

[simsurace]

Ok, but what about spawning an interactive thread?
What is -t 1,1 saying, if not "give me two threads, one of them interactive"?
I think the docs are still not correct then.

-t, --threads {auto|N[,auto|M]}
                          Enable N[+M] threads; N threads are assigned to the `default`
                          threadpool, and if M is specified, M threads are assigned to the
                          `interactive` threadpool; "auto" tries to infer a useful
                          default number of threads to use but the exact behavior might change
                          in the future. Currently sets N to the number of CPUs assigned to
                          this Julia process based on the OS-specific affinity assignment
                          interface if supported (Linux and Windows) or to the number of CPU
                          threads if not supported (MacOS) or if process affinity is not
                          configured, and sets M to 1.

[oscardssmith]

The problem with is that while spawning with 1 normal and 1 interactive thread, users of nthreads generally use it to determine "how many threads can I schedule my heavy computation on" and then the answer to that question shouldn't include the interactive thread(s). The real problem as @vtjnash said is that nthreads is no longer a function that really makes sense to ask.

[simsurace]

Thanks, I get this part. My remaining problems are

• The docs seem to be wrong then. The page on threads says that nthreads() should be 2 here.
• I would still expect to be able to spawn the single interactive thread that I asked for here:

$ julia +beta -t 1,1

julia> fetch(Threads.@spawn :interactive Threads.threadpool())
:default # expecting :interactive```

[carstenbauer]

Threads.nthreads is soft-deprecated, for this and other reasons. Don't use it anymore.

I knew this already, because @vtjnash pointed it out on Slack the other day as well, but is this mentioned anywhere (in the docs)?

If there isn't a visible comment about this in the docs yet, there really should be, IMHO. It isn't particularly great to soft-deprecate something as prominent as nthreads, or have it be unreliable (in the sense that it doesn't give the total number of threads for many reasons, e.g. because that's a dynamic concept now anyways), without clearly communicating this. Kind of reminds me of threadid(), which suggests to be very intuitive and simple but really is a footgun, especially now that we default to dynamic scheduling for @threads.

[IanButterworth]

Perhaps a maxlog=1 warning would help #48589 (closed)

[jakobnissen]

If nthreads is being deprecated, what mechanism should be used to determine the number of threads that can run at a given time? This information is needed in many threaded programs.

[simsurace]

I'll open a new issue for the inability to spawn an interactive thread as it does not get enough attention IMHO.