[External] : Re: Thread vs Tasks

[Ron Pressler]

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<mailto: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