4 ms·

It is an unfortunate abuse of an existing facility for something quite different.

pron 6y ago
The API is not yet final, but I wonder why you think it's "an abuse of an existing facility for something quite different," and whether this could just be a matter of a habit rather than purpose. Take a look at the description of ExecutorService (https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/concurrent/ExecutorService.html https://docs.oracle.com/en/java/javase/15/docs/api/java.base...) and Executors (https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/concurrent/Executors.html https://docs.oracle.com/en/java/javase/15/docs/api/java.base...). I think we're using them exactly as intended: those are APIs meant to manage and control task's execution and lifetime. I'm interested to hear why this feels wrong to you.
- kasperni 6y ago
  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 creation. When used with SC they are suddenly created and thrown away without a blink. And are mostly tasked with coordination. So people will probably need some time to adjust.
  - 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()); } ... } ...

pron 6y ago

The API is not yet final, but I wonder why you think it's "an abuse of an existing facility for something quite different," and whether this could just be a matter of a habit rather than purpose. Take a look at the description of ExecutorService (https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/concurrent/ExecutorService.html https://docs.oracle.com/en/java/javase/15/docs/api/java.base...) and Executors (https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/concurrent/Executors.html https://docs.oracle.com/en/java/javase/15/docs/api/java.base...). I think we're using them exactly as intended: those are APIs meant to manage and control task's execution and lifetime. I'm interested to hear why this feels wrong to you.

kasperni 6y ago
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 creation. When used with SC they are suddenly created and thrown away without a blink. And are mostly tasked with coordination. So people will probably need some time to adjust.
- 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()); } ... } ...