3 ms·

I think the common mental model of an ExecutorService for most people is something static and heavyweight and whose main task is to avoid expensive thread creat

• pron 6y ago
  Some adjustment to the fact that threads are not necessarily costly resources will be required, but would putting the newThreadExecutor (and the specialised newVirtualThreadExecutor) method in a class other than Executors, where it is one among many other methods, and perhaps have it return a subclass/interface of ExecutorService make the adjustment easier? This is something we're seriously considering (especially as that particular ExecutorService might have other implications, such as how thread dumps are produced).
  • kasperni 6y ago
    I appreciate the cleverness of just adding AutoClosable to ExecutorService. But I definitely think returning a specific subclass/interface of ExecutorService would be a great help. I think at the expense of an extra class, something like this is a lot easier for people to wrap their head around: try (Nursery n = Nursery.spawn()) { n.submit(() -> foo()); n.submit(() -> bar()); } try (Nursery n = Nursery.spawnWithDeadline(Instant)) { ... try (Nursery nx = n.spawn()) { nx.submit(() -> foo()); nx.submit(() -> bar()); } ... } ...