Re: [ANN] article: Structured concurrency and Lua

[Sean Conner <sean@...>]

It was thus said that the Great David Sicilia once stated:
> >
> > From experience using nurseries for over 3 years in a large, production,
> > Python app:  cancelling children on non-error scope exit is not the desired
> > semantics, 95% of the time.
> 
> I think it depends on what the "tasks" are for.  If a task is a kind of job
> that runs in a finite amount of time and produces some useful
> result/computation, then why would you issue a return statement before they
> have completed?  

  This thread (if I understand it correctly) is about structured
concurrency.  A good description of which is:

https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

  There's a technique Apple uses (I forget the name) to connect to a service
with multiple IP addresses.  They attempt to connect to each one at the same
time, and which ever one connects first is the one used.  Using structured
concurrency this is trivial:

	  local function connect_to(host,port,result)
	    result[host] = tcp.connect(host,port)
	  end

	  local result = {}
	  local tasks = nursery()
	  tasks:spawn(connect_to,'192.168.1.10',80,result)
	  tasks:spawn(connect_to,'fc00::1:6',80,result)
	  tasks:wait_any()

> Don't you have to wait for them to complete in order to
> get their results, and then use those to produce the return value or as
> input to a subsequent computation?  

  In the example above, we don't want to wait for all of them to complete,
we only care about one of them completing.

> And if that is not the case, then I
> would argue that those tasks are not essential, and could just as well be
> cancelled upon issuing the return statement (which causes control flow to
> leave the current scope).
> 
> If we insist on waiting for the tasks to complete whenever we leave the
> scope for non-error reasons, then we also have an asymmetry/inconsistency
> of behavior when leaving the scope; i.e., the fate of the tasks depends on
> the precise way in which we leave the scope, which I think makes programs
> harder to reason about in a way.

  My understanding of this is that when you have (at least from what I've
seen so far):

	do
	  local tasks <close> = nursury()
	  nursury:spawn(...)
	  nursury:spawn(...)
	  nursory:spawn(...)
	  -- do some other stuff, that might error
	end

  Is that the program won't leave the scope until all the spawned coroutins
have finished doing what they do, unless you have explicitly cancelled them
before you leave the scope.

  -spc