Loom on Scala

[Alan Bateman]

On 27/11/2021 23:12, Eric Kolotyluk wrote:
> :
>
>
>     - This is a perfectly valid expression of logic because
>     furtureResults.map(_.get) will wait/block until all the Futures have been
>     completed, which implicitly is the same as a join().
>     - Project Loom is an extension of the JVM and libraries, not the Java
>     Language. Other language users, such as Scala, should not be penalized by
>     having to use join() when it is not semantically necessary.
>     - Even in Java, join() should not be necessary because it is possible to
>     wait for all Futures to be complete by other means.
>        - Indeed, close() should be able to detect if all tasks have
>        completed, even if join() has not been called.
>        - It is reasonable to expect StructuredExecutor#close to implicitly
>     join() if necessary,
>        - and throw an exception when appropriate, even if this requires
>        wrapping try-with-resources with another try to catch the
> closing exception.
>        - yes, this would be really ugly, but we have trade-offs on where
>        ugly and beautiful present themselves
>     - In some cases, it's really important/useful to call join, such as
>     dealing with any completion failures, but there are other mechanisms to
>     catch those failures.
>
> My sense is that requiring join() before close() is a kluge, and I invite
> someone to convince me otherwise. I am not trying to insult anyone, just
> convey an emotion, and I am willing to be convinced otherwise.
>
>     - Yes, calling join() before close() is an extremely good practice for
>     many reasons, but it's not always semantically necessary.
>     - Is calling join() before close() a seatbelt where Loom is trying to
>     protect us from ourselves?
>     - Is it too much work to implement this otherwise?
>     - Is there some hard-core technical reason why this is necessary?
The intention (and we tried to make this clear in the javadoc) is that 
the check to ensure join is called is to help guide developers to use 
the API as intended. You are correct that if you do your own bookkeeping 
then you could invoke Future::get for every task. That would be O(n) 
wait/wakeups and more complex once you you have to deal with tasks that 
fail.

-Alan