Naming Things - Task and Subtask

[Holo The Sage Wolf]

but I would just create something like this on top of STS

Definitely possible (and it is how I made my PoC), but the point I was
trying to make is that there should be some base TaskScope that does not
touch the other constructs and for other constructs we should use a
different StructuredTask implementation.
One can easily implement StructuredTask.lambdaScopedBuilder(...) (name in
progress) which works as Eric’s example.

Now that I re-read the mailing chain I realised that my
StructuredTask.stream is not what Eric talked about, but I still stand by
my point that if we add such a construct to the API, it should be separated
from the “basic” one.

If you have a working implementation of something like this, I would be
curious to see it

Unfortunately I only have a partial implementation at the moment, and it is
sitting in a closed network. I will try to get it out/rewrite it and upload
it to git to share it when I can.

Though I suspect an actual implementation has to go through some iterations

Definitely, in the actual API I have apart from flatFork also fork
(obviously), forkMulti, flatFanIn (see bellow) (I didn’t implement
fanInMulti yet, but conceptually it is there, although a bit more tricky to
implement because of short-circuit), exit (anly accessible after flatFanIn,
you put a condition based on number of iterations and time for when to
short-circuit the fanIn mod), joinAll (equivalent to the standard
StructuredTaskScope), joinTillFirst (equivalent to ShutdownOnSuccess),
joinTillFailure (equivalent to ShutdownOnFailure) and start (start can be
called only after one of the joinX was called). After a “start” call, you
are left with a normal stream

The API is certainly not perfect and is more of a PoC (e.g. it always saves
the results and the exceptions in fanOut mod, and never in fanIn mod, apart
maybe from the last task finished), also apart from heavy pipe-lines I
prefer to not use this style of coding, so I never actually planned to
promote this from PoC.

To handle situations like you described I made the fanIn mod, which
basically just runs repeatedly till the exit condition is met or is called
to exit from one of the subtasks in creates:

StructuredTask.streamBuilder() // in actuality it is not part of
"StructuredTask"
                   .flatFanIn(() -> serverSocket.accept())
                   .exit((count, time, absoluteTime) -> ...) // count
is the number of "events" fired, "time" is time since last "event",
"absoluteTime" is time since entering "fanIn" mod
                   .fork(ctx -> ...) //in "fanIn" mod fork has a
"context" of the mod, which allows an individual task to access it's
`count, time, absoluteTime` as well as exiting the mod
                   .joinAll()
                   .start(); // empty stream, because it is fanIn mod

And also compare how particular cases would compare against Stream, because
your example looks like more of a candidate of parallel Stream

It is a similar API to a stream, it is also structured concurrency.

It also has nothing (okay, maybe not *nothing*) to do with parallel stream
apart from the similar function call chaining, the semantics of “parallel
stream” in Java is that the parallelism works together in completing a
transformation on the input (as evidenced by the reduceand collect
methods), and in general in the Stream interface there are a lot of methods
that doesn’t make sense for the StructuredTaskStream

On Fri, May 19, 2023 at 10:43 PM Attila Kelemen attila.kelemen85 at gmail.com
<http://mailto:attila.kelemen85@gmail.com> wrote:

>
> > Attila (and still Eric)
> > It seems like both of you don’t like the TWR part, but I find it
> extremely nice to have, and a lot of times prefer it over a lambda argument.
> > TWR allows us to propagate checked exceptions, which till we add
> union-types in generic levels is impossible to do with lambdas, and it
> doesn’t have the (justified) restrictions of lambdas.
>
> I'm not really against having the TWR way available as a low level
> construct, I just like to have these lambda blocks as utility to which
> you resort to (although tbh, it is a bit strange that scoped values
> give you lambda block only, while STS only TWR). Of course, checked
> exceptions are a nightmare in these constructs, and that is why I
> usually have `UnsafeFunction<T, E extends Throwable>` (and its
> gazillion siblings) around (and I'm pretty sure there are many-many
> people creating their own "Unsafe" function interfaces). In an idea
> world we could have constructs similar to Kotlin's inline functions,
> which would solve this issue (fingers crossed for it :))
>
> >
> > var results = StructuredTask.StreamBuilder()
> >                                    .value<String>("USERNAME", "duke")
> >                                    .flatFork(() -> Stream.of(workers))
> >                                    .join()
> >                                    .throwIfFailed() //
> "StructuredTask.Stream" doesn't need a "strategy" because it exposes
> functions like this instead
> >                                    .map(Subtask::get) // "structured"
> comes into play here, you can't call terminating operators without first
> calling "join"
> >                                    .toList();
> >
>
> This could be nice actually, but I would just create something like
> this on top of STS, since an API like this could easily end up with
> unwanted limitation. If you have a working implementation of something
> like this, I would be curious to see it. Though I suspect an actual
> implementation has to go through some iterations (at least, when I'm
> designing APIs like this, I always have to seriously review my
> original idea). In this idea - for example - I can't see how you would
> do a conditional termination of starting new workers in a loop. For
> example, if this was a server waiting for TCP connections, and then it
> needed to fork new tasks for each incoming connection, I'm not sure
> how that would look. And also compare how particular cases would
> compare against `Stream`, because your example looks like more of a
> candidate of parallel `Stream`.
>
-- 
Holo The Wise Wolf Of Yoitsu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230519/f314f6a9/attachment-0001.htm>