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

[Ron Pressler]

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. 

As older applications would need to be changed somewhat, anyway, to enjoy structured concurrency (as even the ExecutorService API were to support structure, it would need to be changed to do so, and so the use-sites would need to be changed as well), they might as well use the new mechanism and spawn a virtual thread per task.

As Brian says, the existing thread pools are also grouped in the new thread dump, but because their use is unstructured, you won’t get the full structured hierarchy (as it isn’t defined). We might consider adding a manual way to create a hierarchy of threads even without structure.

— Ron
 

> On 18 Nov 2021, at 20:09, Ignaz Birnstingl <ignazb at gmail.com> wrote:
> 
> Hi Ron,
> 
> regarding the StructuredExecutor:
> The design of this API seems to be very VirtualThreads-specific. Did you consider using an ExecutorService instead of - or in addition to - a ThreadFactory for dealing with tasks?
> I could see these benefits:
> (a) With an ExecutorService you could regulate the concurrency level by using a thread pooling ExecutorService - or use a ThreadPerTaskExecutorService like what is done with the ThreadFactory API.
> (b) If the whole structured thread dump thing would be moved to ExecutorService, older applications which use ExecutorServices could benefit from it, too. I'm not sure if this is technically possible, though.
> 
> Ignaz