Meaning and Usage of Tasks

[Ron Pressler]

You bring up multiple points, so let me try and address them.

A task is, indeed, not a thread, and, as you say, I would simply consider it to be some computation, usually expressible as a lambda expression/method reference. Because StructuredExecutor spawns a new thread for each forked task, we might sometimes use the terms interchangeably, but only in this context.

As to the method names and signatures, the execute method is there simply so that StructuredExecutor could implement the Executor interface that declares it. You’ll find something similar in ExecutorService, where there’s a method called executor, that takes a Runnable and returns void, and methods called submit, which take a Callable and return a Future. StructuredExecutor.fork is analogous to ExecutorService.submit. Now, ExecutorService also has an override of submit that takes a Runnable (and returns a Future), in addition to the void execute method. We could certainly add a similar override of fork, but it didn’t seem particularly urgent at this point in time. You can always turn a Runnable into a Callable with the Executors.callable [1] helper method. If you find this to be too much of an inconvenience, please let us know.

— Ron

[1]: https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Executors.html#callable(java.lang.Runnable)

> On 18 Nov 2021, at 20:18, Eric Kolotyluk <eric at kolotyluk.net> wrote:
> 
> Reading some of the documentation I am getting confused about the meaning
> of a 'Task' and wrote about this earlier in Threads vs Tasks...
> 
> Initially, these were just Runnable, and then could also be Callable (which
> is better). Is it interesting to note in StructuredExecutor there are
> different signatures for
> 
> .execute(Runnable)
> .fork(Callable)
> 
> And I appreciate the distinction because calling .submit(Runnable |
> Callable) can blur things, but can also see that .submit() may be more
> attractive to some. Also, Callable can throw a Checked Exception, whereas
> Runnable cannot. Can someone please explain the reason for this design
> change?
> 
> I especially appreciate that both Runnable and Callable can be expressed
> with Lambda expressions, especially coming from a background of Akka/Scala,
> where Actors .spawn() other Actors, and can use Lambda expressions.
> However, in Akka Typed we often use forms such as
> 
> object GreeterMain {
> 
>  final case class SayHello(name: String)
> 
>  def apply(): Behavior[SayHello] =
>    Behaviors.setup { context =>
>      val greeter = context.spawn(Greeter(), "greeter")
> 
>      Behaviors.receiveMessage { message =>
>        val replyTo = context.spawn(GreeterBot(max = 3), message.name)
>        greeter ! Greeter.Greet(message.name, replyTo)
>        Behaviors.same
>      }
>    }}
> 
> where the Behaviors.setup { context => ... is a Lambda that takes a
> 'context'
> 
> Now I am not advocating adopting the Akka style, but it makes me wonder
> what it would look like if we had capabilities like
> 
> structuredExecutor.spawn( () => {task implementation} )
> structuredExecutor.spawn( context => {task implementation} )
> structuredExecutor.spawn( (context, thingy) => {task implementation} )
> . . .
> 
> and so on, where context is something not available in the session because
> the structuredExecutor is available to the task implementation. I am just
> thinking out loud here, where not all Tasks need the context, thingy, etc.,
> but some may benefit from them. More importantly, is there some concept of
> Task that goes beyond Callable, that cannot be satisfied by adding more
> features to Callable?
> 
> I am pretty sure the Loom Architects have already walked down this path so
> I would like to know if they could share their thoughts on this.
> 
> I am not hung up on a single .spawn() for multiple task types, but I like
> the name because it brings a sense of 'family' to concurrent programming. ��
> 
> In my mind, a Task is *not *a Thread, it is something else that can be
> executed on a Thread, but it should always be implementable by a Lambda.
> 
> Cheers, Eric