On Fri, Aug 17, 2018 at 06:36:36PM +1200, rikki cattermole via Digitalmars-d wrote: > After reading the article I can say, it isn't any better than async > and await for dependencies. You still need an event loop. > > The problem is that joining that happens at the end of that block > needs to run the event loop for iterations until it completes. Which > is wonderful if you're not doing real time like game development.
I don't see the problem. The event loop can spawn tasks into one main nursery, and each task can spawn subtasks into its own nurseries. The nursery in the task blocks until the all subtasks have completed, *but* that does not preclude other tasks in the event loop's main nursery from running simultaneously, e.g., to handle events and timers. > In essence you want a stack of state per thread, which uses the central > event loop: > > func(): > with x: > spawn(foo) > join(foo) > endScope() > funcParent(): > with x: > spawn(func) > join(func) > endScope() > > If you don't have this, you will miss timers, window events and all > sorts of things that could be very time sensitive which would be very > very bad. Why will you miss timers and window events? The event loop will spawn tasks into one nursery, while tasks spawn subtasks into their own nurseries. While the task nurseries are blocking to join subtasks, the event loop nursery continues running simultaneously. It doesn't join until the event loop exits. Please elaborate on why you think there's a problem here. I'm not seeing it. > Because we have an event loop, we don't need a nursery! It comes free of > charge. It also means we don't need that with statement... hang on that now > becomes await and async! Just without the await (auto added in scope(exit), > and compiler can merge them into a single function call ;) ). I think you're missing the point here. The point is to create an abstraction of concurrent processes that's easier to reason about. Saying "we have an event loop, we don't need a nursery" is akin to saying "we have unrestricted goto, we don't need structured blocks like functions, loops and else-blocks". The point is not whether you can express the same things, but whether it's easier to reason about the resulting code. Two abstractions may be equivalent in expressive power, but one may be extremely hard to reason about (unrestricted gotos, await / async, etc.), while the other may be much easier to reason about (structured code blocks, nurseries). Abstractions that are hard to reason about tends to lead to buggy code, because the programmer has a hard time understanding the full implications of what he's writing. That's why we prefer abstractions that are easier to reason about. That's the point. T -- Perhaps the most widespread illusion is that if we were in power we would behave very differently from those who now hold it---when, in truth, in order to get power we would have to become very much like them. -- Unknown