[RFC] switch threads to on by default

[arnetheduck]

Currently, --threads:off is the default. I'd like to propose that this is switch to on by default (with a view to remove it completely at some point, or even now).

I remember the good old days, 20 years ago, when C libraries were split between threaded and multithreaded versions - actually, they days were not that good at all. There was lots of confusion, educational effort and annoying issues caused by this:

• developers would link to the wrong one and users would suffer
• developers would start building with the single-threaded version, only to crash and burn on newbie multithreading issues (like mutable globals)
• the multithreaded variant would be of poor quality because it would receive less attention
• people didn't know how to write multi-threaded code that performed well on single-threaded setups
• CPU's were mostly single-threaded
• poor API were developed (think about all those _r variants in the C library, or errno actually being a function call hidden behind a macro etc)

In most cases, code that is thread safe can also be used in single-threaded setups. Thus, I'd recommend we turn threads on by default in nim:

• when writing single threaded code, you won't notice the difference
• less confusion when you want to write multi-threaded code
• the multithreaded variant of nim will gain quality
• there will be fewer poor nim API's in the world
• there will be fewer poor API's in nim itself (yeah, looking at you, rand and friends)
• there will be fewer options to test separately in nim, contributing to its overall quality

alternatively, we make the option a noop / deprecated (I actually prefer this option - much more simple) - if it really matters, the compiler can be made smart enough to detect if threads are actually used

[Araq]

Completely agree and wanted to bring this up one day myself... :-)

Btw rand has variants that take an explicit state object so IMHO it has no problem wrt threading.

[timotheecour]

can there be any potential drop in performance for single threaded apps with --threads:on ?
if not, then I agree

[arnetheduck]

right, nobody should complain if rand is actually random, right?

[timotheecour]

not sure what you mean? in reference to https://github.com/nim-lang/Nim/issues/9878#issuecomment-445050346 as long as there's an option (which doesn't have to be the default) to get maximum performance (even if that means single thread, and even if that implies rand doesn't work), than changing the default to --threads:on is fine.

with a view to remove it completely at some point, or even now

that would be undesirable if it affects "max performance for apps that don't care about multi-thread"

[Araq]

@timotheecour Thread local storage continues to be slightly slower than global variables and it not as well supported on less common (embedded) platforms. But we map .thread to nothing if --threads:off and that's good enough. It does mean --threads:off will stay around for some time though.

[dom96]

As long as issues like these pop up then I don't think we're ready to do this: dom96/nim-in-action-code#6

The GC safe system in Nim is still a tad too annoying and enabling threads turns warnings into errors.

[Araq]

I disagree, you can use your globals in a {.gcsafe.} environment. (Yes, that is somewhat new.)

[ringabout]

implemented by nim-lang/Nim#19368