Structured Concurrency yet again

[Ron Pressler]

On 10 May 2023, at 17:46, forax at univ-mlv.fr<mailto: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).

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


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


— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230510/c6549e48/attachment-0001.htm>