Structured Concurrency yet again

[forax at univ-mlv.fr]

> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Alan Bateman" <alan.bateman at oracle.com>, "loom-dev"
> <loom-dev at openjdk.java.net>
> Sent: Thursday, May 11, 2023 1:36:07 AM
> Subject: Re: Structured Concurrency yet again

>> On 10 May 2023, at 17:46, [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] wrote:

>> Yes, but Go channels also do O(N) wakeups in the worst case (sometimes you can
>> pump several results in one wakeup) and nobody complain.

> Channels aren’t Go’s structured concurrency construct, errgroups are, and they
> block once (at least their API suggests that).

Errgroup is a special construct that is the equivalent of STS.ShutdownOnFailure (you can also implement ShutdownOnSucess because there is a method cancel() (the equivalent of shutdown())). 
Errgroup does not have to cover all scenarios because in Go you can always fallback on using channels. Errgroup is a nice structured concurrency API for some special cases while channels is the more general API. 

In term of typing, Errgroup is not better than STS.ShutdownOnFailure because both erase the type of the error/exception. Note that errgroup what developed before go had generics. 

I believe STS should not focus only on the special cases STS.ShutdownOnFailure and STS.ShutdownOnSucess, but also provides a thread safe way to implement most of the general cases. 
What i am proposing cover all scenarios that could be implemented by a channel with multiple writers but only one reader. For those cases, I believe that the a join(Function<Stream,T>) is a better API than the channel API because it is a structured concurrency API and it's also better than letting users to write a poor man implementation of channels as a subclass of STS. 

>> What i'm proposing is just a glorified blocking queue + a spliterator but it
>> allows to implement any logic more easily.

> Channels are something we’re interested in, but as an orthogonal feature to —
> putting it very simply — solve the “blocking queue closing” problem (and
> perhaps some others, such as distributed implementation, easy functional
> transformations).

yes, 
what i'm saying is not that we need channels, as you said it's an orthogonal feature, what i'm saying is that there is a category of problem that could be solved by a channel with multiple writers and only one reader, for those problem, we can also provide a structured concurrency API. 

>> You're aware that I have demonstrated the Java 19 version of STS to numerous
>> conference attendees. However, the requirement to create custom subclasses is
>> often a point of confusion for them. Many existing APIs attempt to separate the
>> concurrency aspect, which is managed by the implementation, from the business
>> logic that users should focus on.
>> I believe the current incarnation of STS is falling short.

> Can you please try to clearly identify the problem you’re trying to solve? E.g.
> doing X well with STS is hard

Doing anything which is not shutdown on failure/shutdown on success is hard with STS because STS does not help users to write a correct thread safe implementation of a subclass of STS that overrides handleComplete(). 

> — Ron

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230511/52d7856c/attachment-0001.htm>