[External] : Re: A new build and a new structured concurrency API

[Ron Pressler]

> On 19 Nov 2021, at 08:19, Ignaz Birnstingl <ignazb at gmail.com> wrote:
> 
> Hi,
> 
>> The problem is that tasks are not observable entities. You can’t get a “task dump”, and so the relationships among tasks are reflected in their threads, but currently this can only be done if the thread is tied to a single task.
> 
> But at any given time an ExecutorService's worker thread _is_ tied to a single task, or am I missing something? The only exception that comes to mind is a direct executor [1].

That would mean that the thread hierarchy would constantly change; one moment thread A would be B’s parent, and the next it would be it’s child. I’m not saying we rule that out, but we’d rather start with something simpler and stabler.

But my question is, what problem that you ran into with StructuredExecutor are you trying to solve?

> 
> but you could also do
> 
> // Limit parallelism to 5
> try (var s = StructuredExecutor.open("foo", Executors.
> newFixedThreadPool(5))) …
> 

Ah, so if the problem is limiting concurrency, the solution isn’t a thread pool; limiting concurrency isn’t thread pool’s main purpose, and we use them for that purpose only because we use them, anyway, so we might as well use them for that. What we really want to do when we limit concurrency is limit concurrent access to a particular resource — say, the database. A much better way to do that is to employ a semaphore guarding the access to the resource. This way, it can be accessed from any thread, and still limit concurrency. 

I would ask that, instead of trying to think of ways of making StructuredExecutor better, you focus on what *problems* you run into when you’re using StructuredExecutor.

— Ron