A new build and a new structured concurrency API

[Brian Goetz]

Yes, we did.  The ES abstraction felt too weighed down by the assumption that threads are a long-lived entity and needed to be structured into services (with independent lifecycles) to own them.  

Your second concern (b) is already sorted; the ES implementations in the JDK already get their threads grouped in the serviceability view.  

> On Nov 18, 2021, at 3:09 PM, 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