concurrency call to arms

[H. S. Teoh]

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