Structured Concurrency yet again

Alex Otenko oleksandr.otenko at gmail.com
Thu May 11 07:06:04 UTC 2023


:) define "hard". Because the hard bit is "just" creating a subclass of
something or other.

On Thu, 11 May 2023, 00:36 Ron Pressler, <ron.pressler at oracle.com> wrote:

>
>
> On 10 May 2023, at 17:46, 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/20230511/1e3b4def/attachment.htm>


More information about the loom-dev mailing list