rename std/threads to std/typedthreads

[ringabout]

Or should it be typedthreads or thread_v1? I don't know. Suggestions are appreciated.

[PMunch]

Depends on what the new module is going to be called, and what the relationship between them is going to be. The threads module is a fairly thin wrapper over the system threads, how is this going to change with the new threads? Are people still going to use the old threads module if they want this low-level access?

[arnetheduck]

why is it being changed?

[ringabout]

The implementation of std/threads is not good enough. In 2.x, there will be likely to have a better std/threads module. In case of the name conflicts, it needs to be renamed.

[ringabout]

how is this going to change with the new threads? Are people still going to use the old threads module if they want this low-level access?

The new std/threads is likely to have bare primitives and no generics. It should be simply a thin wrapper of system threads while it's not true for the current implementation which stores thread local data and the callback pair.

[arnetheduck]

Developing a new thread module sounds like something that will be a compromise between rushing a poor thread module and delaying v2 - why not leave a new thread module to 2.2? Creating one is not part of v2 goals really.

[ringabout]

Developing a new thread module sounds like something that will be a compromise between rushing a poor thread module and delaying v2 - why not leave a new thread module to 2.2? Creating one is not part of v2 goals really.

In 2.x, there will be likely to have a better std/threads module.

Perhaps I was not clear. As I said, there is no plan for a new std/threads module in v2 release. It will be implemented in 2.x.

[PMunch]

I don't think it's a great look for Nim v2 to have soft deprecated our threads module with no alternative.. I find this a very strange decision, especially considering how --threads:on will become the default and ARC/ORC promises easier multithreading.

[arnetheduck]

I don't think it's a great look

"It will be shipped in 2.2" is an excellent answer to that comment - ie it's perfectly fine, given that nothing was really lost (ie the current threads module is hardly worth bragging about and DIY threading is kind of the norm since none of abstactions work well - the idea with --threads:on is to make sure that the core language parts don't fall apart under DIY threading conditions at least.

[PMunch]

I was more thinking about the publicity spike that Nim will get a v2 release. It will look like Nim v1 had threading but v2 removed it. I'm just saying that it would look a bit odd, even if the old threading module wasn't anything to write home about. In a perfect world I would of course like Nim v2 to ship with a new and improved story for multithreading, but by the look of things that would delay the launch quite significantly (although maybe it would be more deserving of the v2 name).

[Varriount]

I feel that it would be better to deprecate the current "thread" module only when we have a viable replacement. This avoids pressure to release a sub-par alternative because "we need a replacement ASAP".

[Araq]

Let me clear up the situation: The threading primitives moved out of system.nim for nimPreviewSlimSystem. There was no std / threads before so nothing got removed. We're bikeshedding about a name, that's all. And ideally the new name doesn't prevent us from coming with an even better threads module later so typedthreads is a good solution.

[PMunch]

So this module will still be automatically imported when --threads:on? The new typedthreads name is definitely much better, when I started commenting it was called oldthreads which made it appear like we didn't have a new solution for threads.

[ringabout]

So this module will still be automatically imported when --threads:on?

Yeah. It is imported by default (without -d:nimPreviewSlimSystem).

[github-actions]

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from e03a178

Hint: mm: orc; opt: speed; options: -d:release
165126 lines; 8.129s; 614.172MiB peakmem

[arnetheduck]

so hold on - if this is imported automatically and not meant to be a "user" import, why is it in the std namespace?

[ringabout]

Because it is not imported with -d:nimPreviewSlimSystem. Users' code should still work with -d:nimPreviewSlimSystem by simply importing a module. Perhaps we can give an error when users try to import these modules without -d:nimPreviewSlimSystem.