@Araq: **Regarding the `channels` and `threads` libraries use with
`newruntime`...**
> No, I mean they are currently "submodules" of system.nim but there is no
> reason for that, it should be a separate, explicit import.
As I said before, I can see the sense of making these separate modules and
@Araq, @mratsim: As promised, I'm posting some code that shows the current
difficulty of bypassing the overly simplistic (and performance costly) default
behaviour for the current channels and threadpool libraries of deepCopy'ing all
GC'ed ref's so they won't be prematurely destroyed if they go
@mratsim: Thanks for the reply and your correction of my misunderstandings.
> Also the current threadpool/spawn/^ does not work on the "Hello World!" of
> multithreading which for better or worse is fibonacci...
Ah, I understand. So the order of business is still likely correct: get
threading w
Replying mostly to your first reply @GordonBGood
> threadpool/spawn/FlowVar is a beautiful modern concept for multi-threading
Agreed
> So in a few hours I took my wrapper implementations and re-wrote my required
> parts of threadpool to not consider GC'ed data structures in about 150 lines
> (
@Araq:
> (the theads and channels libraries) should be a separate, explicit import.
Okay, I see that.
> (about deepCopy) the answer is "no" because C++ and Rust and C etc. # all
> lack it. ;-)
C/C++ lack deepCopy but then, in spite of their bulk, they aren't very complete
languages are they ;
> What? threads and channels are their own libraries and aren't currently in
> the system library. I think you mean that they won't need to use
> system.deepCopy anymore?
No, I mean they are currently "submodules" of system.nim but there is no reason
for that, it should be a separate, explicit
@Araq: ???
> with --newruntime we shouldn't have threads or channels or deepcopy in system
> anymore
What? threads and channels are their own libraries and aren't currently in the
system library. I think you mean that they won't need to use system.deepCopy
anymore?
We still need the threads l
Sure, sounds good. And yes, with `--newruntime` we shouldn't have threads or
channels or deepcopy in system anymore, all this cruft can be removed and we
can write libraries without compiler magic that do these things better.
@Araq: Good of you to indicate you are following this! Sorry to inflict my long
posts on you, but they are also **written for new users who don 't know the
history and background of Nim**, and I **bold the main points** so those who
are "in-the-know" such as yourself can skim.
> > It appears th
> It appears that Nim's threading model fails at several if not all of the
> above precepts; this is similar to @Araq just recognizing that Nim's GC based
> memory model is likely wrong in that it is taking more and more support time
> and still doesn't make managing memory Simple.
I take that
@mratsim:
We were in the midst of a discussion about multi-threading over on the [Fastest
Primes](https://forum.nim-lang.org/t/4950#31862) thread, but I see why you
haven't replied to that discussion - you've been busy with this Picasso RFC
project. I, too, have been busy investigating multi-th
11 matches
Mail list logo
