[External] : Re: Thread vs Tasks

[Eric Kolotyluk]

Ah, thanks for the explanation of observable.

Here are the problems I ran into

   1. Understanding the JavaDoc for StructuredExecutor, as I had to ask
   questions here, that could have been addressed by clearer documentation. I
   would be happy to offer to revise the documentation.
   2. Understanding the ontology and taxonomy of Project Loom, and Java
   Concurrency as a whole. Sometimes this is expressed in documentation, but
   often it can be revealed in design. Again, I had a problem figuring this
   out, and I still have a long way to go.
   3. My “but wouldn’t be even cooler if…” was an attempt to see a problem
   down the road that might affect me...
   4. StructuredExecutor introduces "sessions" which in this case is a
   non-overlapping sequence of phases Open -> Forking -> Joining -> Error
   handling and other housekeeping -> Closed. This is very new and different
   and it took me a while to really appreciate it by trying to document it
   myself, but in the Loom design and documentation, it does not reveal itself
   to me easily. Overall, I think sessions are a really great concept where
   Structured Sessions are one of several types that could be useful.
   5. Structure Concurrency introduces new concepts, that might apply
   elsewhere, but are localized to StructureExecutor. Granted, in the
   beginning, this is more a Proof of Concept or Proof of Technology and may
   change later as a preview feature.

Again, I don't want to dissuade the path you are on, so this is more of
what I would like to see in the future.

Cheers, Eric


On Thu, Nov 18, 2021 at 2:53 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

> By “observable” I mean observable by tooling, i.e. something that directly
> recorded, accessed, or manipulated by debuggers, profilers and
> troubleshooting tools. Threads are already a central entity for those
> tools; futures are not. Because structure for us means not only clearer,
> more correct code, but observability, and because the hierarchy is reified
> in *threads* so that it can be observed by tools, things that don’t spawn a
> thread per task can’t currently provide the structure we’re seeking.
>
> Also, using a thread-per-task is almost always safer and more correct than
> a shared thread pool, and switching to a construct that does it is no more
> work than switching to using other kinds of structured APIs.
>
> But rather than do a random walk through the large solution space, we
> always try to focus on the *problem* (and that’s the way most JEPs are
> structured). That is why the most powerful, helpful, and wise feedback
> takes the form, “I used this thing and ran into this problem.” Pinpointing
> and clarifying a problem is often harder than picking a solution. Focus on
> that: what problem did you run into when using StructuredExecutor that
> prompted you to look for other solutions?
>
> Thoughts of the kind, “but wouldn’t be even cooler if…” are perfectly
> fine, but the real leaps are made when we identify real problems and solve
> them.
>
> — Ron
>
> On 18 Nov 2021, at 22:13, Eric Kolotyluk <eric at kolotyluk.net> wrote:
>
> Sorry, forgot to reply to all
>
> thought Tasks were observable and manageable via their Futures?
>
> Okay, if StructuredExecutor is like ThreadPerTaskExecutor, then that makes
> sense to me. This allows for the possibility of other types of
> StructuredExecutor in the future...
>
> Instead of creating a new type of Executor, why not create another object
> that is passed to the Executor as a parameter, the way the ThreadFactory is
> passed. For example, via a SessionFactory, where one of the Session types
> is StructuredSession, then all Executors could be extended with Structured
> Concurrency.
>
> Then we could have something like
>
> var virtualThreadFactory = Thread.ofVirtual.factory()
> var structuredSession = Executors.newStructuredSession(. . .)
> var structuredExecutor =
> Executors.newThreadPerTaskExecutor(virtualTheadFactory, structuredSession)
>
> In this way, Structured Concurrency is more applicable to more contexts...
> not that you need to implement it for all contexts now... maybe just
> .newThreadPerTaskExecutor() for now...
>
> Also, .fork() and .join() would be session methods, not executor methods...
>
> This introduced two new concepts, Sessions, and Structured Sessions...
>
> Just thinking out loud again...
>
> Cheers, Eric
>
>
>