`export JULIA_NUM_THREADS=X` sets `nthreads(:interactive)=0`

[oscardssmith]

A lot of people have an exported value for JULIA_NUM_THREADS that doesn't specify a second number (because they set this up prior to 1.9). Julia 1.9 added interactive threads, but they are disabled by this line unless JULIA_NUM_THREADS manually sets a number of interactive threads. This isn't exactly a bug, but I think the better behavior would be to default to 1 interactive thread unless JULIA_NUM_THREADS=X,0 is used.

[oscardssmith]

(cc @kpamnany)

[kpamnany]

What if JULIA_NUM_THREADS is not defined? Right now, Julia will start 1 default thread and no interactive threads. Should this change?

What about the folks who have no need for interactive threads? Right now, Julia will start the number of threads they specified. With the suggested change, an interactive thread will be started when previously it wasn't and they'd have to change their setting to X,0 to get back the old behavior.

Not arguing, just pointing out that such changes will force somebody or other to make a change.

[oscardssmith]

IMO if JULIA_NUM_THREADS isn't defined Julia should start with 1 interactive thread. The reasoning for both of these suggested changes is that the cost of having an interactive thread that you don't want (IIUC) is a couple kb of memory, while the cost of not having one when you want one is a lot more noticable.

[robsmith11]

The current default behavior could be made more clear IMO.

Reading the command line docs, I had incorrectly assumed that omitting the number of interactive threads would result in 1 interactive thread being used, but apparently that's only the case if --threads *,auto is passed. What's even the point of auto for interactive threads if its synonymous with 1?

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

Getting slightly off topic, but it was also confusing to me that when started with --threads 8,1 the following would only use 1 thread:

julia> Threads.@threads for _ in 1:8
        while true
        end
       end

But starting with --threads 8 would use all 8 threads. Apparently because @threads will use the default pool when there are no interactive threads, but only use the interactive pool when called from the REPL. It would help if this were explained in the docs.
So I don't think 1 interactive thread would be a good default for most people.

[oscardssmith]

I think that might be a bug in @threads

[robsmith11]

I think that might be a bug in @threads

I've filed a separate issue: #50438

[visr]

This is fixed by #57087:

1.11.5
default              1,0
--threads 3,auto     3,1
--threads 3          3,0
JULIA_NUM_THREADS=3  3,0

1.12.0-beta4
default              1,1
--threads 3,auto     3,1
--threads 3          3,1
JULIA_NUM_THREADS=3  3,1