Structured Concurrency yet again

[Ron Pressler]

> On 11 May 2023, at 09:24, forax at univ-mlv.fr wrote:
> 
> 
> 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.

I’m not sure I see how channels generalise SC, but we’d like to have channels too, and in the meantime we have all of the existing classing in j.u.c at our disposal. The real low-level mechanism underneath STS is the ThreadFlock — as that’s what integrates with observability — and we’d like to expose that, too, eventually.

> 
> 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. 

What do you mean by *the* type? In many (most?) fan-out situations, tasks even have different *return* types.

> 
> 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.

Again, before proposing something, I need to understand what problem you’re trying to solve. Without articulating the problem it’s very hard to evaluate solutions for it.

> 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 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.

Isn’t join(Function<Stream,T>), why t that something that a subclass of STS couldn’t offer? Isn’t it a matter of identifying a third common use-case (that solves a problem we’ve yet to articulate) beyond SutdownOnFailure/Success and offering a third built-in policy? 

> 
> 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().

1. How common is “anything that isn’t SoF/SoS”? Are you saying, wouldn’t It be nice to also offer convenience policies for some less-but-still-common use cases, or are you saying there’s a fundamental problem with the design of STS and, as a result, it doesn’t address some of the most common cases? If it’s the former, then perhaps we should wait and see which use cases pose a particular problem to users so we could better design a solution to fit the problem; if it’s the latter, then I think you’ll need to put a finger on the problem.

2. Does STS not support the example you’ve shown (and others you alluded to) with a single additional reusable policy?

— Ron