Consider not throwing ExecutionException in structured scopes

[adamw]

Instead:

• rethrow the exceptions verbatim?
• use an unchecked wrapper exception
• consider tunneling

See the reddit thread

[fluentfuture]

Was just pointed to the latest JDK StructuredConcurrency javadoc. Looks like they've made all these exceptions unchecked (https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html):

• ExecutionException -> StructuredTaskScope.FailedException (unchecked)
• TimeoutException -> StructuredTaskScope.TimeoutException (unchecked)

Looks like a welcome change to me. Although, I'd love to learn your thoughts on the latest API design (still has that trying-to-do-too-much feeling).

https://www.reddit.com/r/java/comments/1fazdkl/structuredtaskscope_vs_parallel_stream/

[adamw]

@fluentfuture oh that's interesting, thanks for the link! The API seems much better: StructuredTaskScope.open provides a useful default (throw if any subtask fails - as in jox), and there's one less API method to call (.throwIfFailed). On the other hand, still using .get before .join is illegal - so the jox-approach while being in one way more limited (one fixed "Joiner" implementation, using the JEPs terms), is in another way more flexible - you can join individual tasks before the whole scope is joined. And I'd still say that's an approach that I'd prefer.

Jox of course will be able to use the new API under the hood.

As for exception handling - if a Java JEP itself departs from using checked exceptions, I think that's a done deal. I suppose we'd end up throwing a custom Jox-defined runtime exception then?

[fluentfuture]

Yeah. We are having discussions in that thread. My latest thoughts on these racy-flavor of concurrency:

https://www.reddit.com/r/java/comments/1fazdkl/comment/lm5p3bp/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Feel free to chime in. :)

[fluentfuture]

You can join individual tasks before the whole scope is joined.

Wondering what kind of memory consistency you provide in that case? In naive structured concurrency, say, if you block on Thread.join() oe ExecutorService.awaitTermination() or Furure.get() on all returned ftures, it provides a hard happens-before guarantee in that after you are past that point, all side-effects performed by the concurrent operations happen before the following code that read them.

This is also true with Mug's concurrently(), and I guess Jox's par() as well. But if you let the user code proceed without blocking on all operations, is it fair to say that no side-effect is safe because there is no happens-before?

[adamw]

@fluentfuture sorry for the delay :) The joined & joining threads synchronise using an equivalent of an AtomicReference, so as you write there's a happens-before relationship. This doesn't affect other threads in the same scope (at least in theory), but I think that this doesn't make side-effects in other threads unsafe, as they also don't get "unsynchronised" information from outside?