A few more random thoughts:
Austin proposed
{
thread { print "hello\n" };
print "world";
}
would spawn the first print into a separate thread, and then join before
executing the second print. I would like to see if this can be extended a
bit, using Luke's "object Sigil" proposal:
my $result = thread { slow_calc() };
# do some stuff;
&$result.join;
print $result
And then use one of my proposals ("lazy_thread") so that $result would be a
"lazy" variable that did an implicit join when it is used. Thus:
my $result = thread { slow_calc() };
# do some stuff;
print $result; # implicit join;
This enables us to separate the lexical scope of the "cothread" object from
the scope of its execution.
But then I started thinking about iterators. Imagine you have a thread that
spits out values, periodically:
for thread {generate} -> { consume }
With coroutines, these two routines would ping-pong between themselves. But
if you want them to run in parallel, then we could create an implicit fifo
between the generator an the consumer. If we were really clever about it (I
think this is what MikeL wants), the code for C<generate> and C<consume>
would be broadly independent of the execution mode. Though there could
clearly be an expectation:
for thread { my $a=0; sleep 1 and yield ++$a while $a<10 } -> $t
{
print "time=$t\n"
}
then s/thread/coro/;
Dave.
