The underlying mechanism needed for this is here:
[https://github.com/nim-lang/Nim/pull/12372](https://github.com/nim-lang/Nim/pull/12372)
It contains a race condition that needs to be fixed, and then flowVar
refactored to use this mechanism.
Unfortunately, Progress has stalled due to several f
What's the status of this?
> Sorry to be cheeky, but, New Nim users (and programmers in general) need to
> learn the difference between concurrency and parallelism. :-P
Thank you! I'll be honest and say that I've actually learned this myself when I
was writing Nim in Action. This is also why I spend quite a bit of the boo
No, my definition is not exact, but I hope it was good enough to get the point
across.
Technically, in the most pedantic sense, a "thread" is a unit of execution (a
stack, a set of registers, and an instruction pointer).
By that technical definition, a "thread" is a unit of concurrency, you are
> This is a common confusion.
>
> Threads: Literally running two different pieces of code in parallel at the
> same time, on two physically different CPU cores.
Are you sure your definition is exact? I have the feeling that threads often
mean concurrency, which is not parallel. See
[https://st
many thanks for your detailed explanation - so it was my misconception of the
"front end compiler trick"
> Just for reference, the main thing that I think we need delivered is the
> ability to await a FlowVar. You can already poll a FlowVar which allows you
> to sort of await it in a poor-man's fashion. await (spawn foo()) should Just
> Work (TM) and work in an efficient manner, i.e. the waiting fo
> So the question could be: whats the audience/usecase for async/await -
> feature vs threads? new Nim users could be confused about that (like me).
>
> I don´t think it´s a good idea to "marry" both - but that´s just my humble
> 2cts..
Sorry to be cheeky, but, New Nim users (and programmers in
@Mikra, It's nice to find another Joe Duffy fan. His posts are long, but always
super interesting!
Actually, Nim's implementation of async is actually _very_ similar to the C#
version, which is very similar to the Node version, which is how old Python did
it.
TLDR; they all read the same paper
I meant that the async implementation of nodejs compared to the c# ones seems
to be different:
[https://nodejs.org/en/docs/guides/dont-block-the-event-loop](https://nodejs.org/en/docs/guides/dont-block-the-event-loop)/
and
[http://www.garethrepton.com/AsyncAwait](http://www.garethrepton.com/Asy
> A vocal portion of the community has not bought into newruntime, or is
> keeping the GC for other reasons, but everyone has accepted async.
This. 👑
Thank you for writing this. I've only skimmed it, but what I've read makes
sense in general. Keep in mind that we already have issues for most th
> Nim´s one is more like in node.js (I think). If you process large chunks at
> once or a endless loop is placed inside you will break your entire system...
No idea what you mean here exactly, but it sounds wrong.
@rayman22201 Well yes. What you write makes sense. Now we "only" need to write
the code... :-)
the blog link is nice, thank you very much. Its long but worth read:
`C#’s implementation of async/await is entirely a front-end compiler trick. If
you’ve ever run ildasm on the resulting assembly, you know: it lifts captured
variables into fields on an object, rewrites the method’s body into a
**Preface to the Preface**
I have been reading into async, and Nim's implementation of async. @Dom96's
book is amazing on this subject btw. much cudos... I have also been going down
the rabbit hole of reading Joe Duffy's amazing blog and the Midori project
([http://joeduffyblog.com/2015/11/19/a
15 matches
Mail list logo
