6 ms·

I don't quite get the point of the executor service with virtual threads. If they are really cheap to create then why not just create them as required? It's bee

I don't quite get the point of the executor service with virtual threads. If they are really cheap to create then why not just create them as required? It's been a while since I programmed in Java though, am I missing something? Edit: Ah - I read the rest of the article. Using it as a synchronisation primitive makes sense I guess, if a bit clunky.

kasperni 6y ago
In the examples with structured concurrency. The point of using an executor service is not to reuse the threads. But instead to control their termination. If you read Nathaniel J. Smith's primer [1] on structured concurrency. The ExecutorService in the examples act as the nursery. Loom is just being "lazy" and reusing ExecutorService for something that it wasn't originally intended to do. Earlier versions had a specific class called FiberScope [2]. Whether or not we will see more specialised classes for this in the future I don't know. [1] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... [2] https://www.javaadvent.com/2019/12/project-loom.html https://www.javaadvent.com/2019/12/project-loom.html
jnwatson 6y ago
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()); } ... } ...

kasperni 6y ago

In the examples with structured concurrency. The point of using an executor service is not to reuse the threads. But instead to control their termination. If you read Nathaniel J. Smith's primer [1] on structured concurrency. The ExecutorService in the examples act as the nursery. Loom is just being "lazy" and reusing ExecutorService for something that it wasn't originally intended to do. Earlier versions had a specific class called FiberScope [2]. Whether or not we will see more specialised classes for this in the future I don't know. [1] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... [2] https://www.javaadvent.com/2019/12/project-loom.html https://www.javaadvent.com/2019/12/project-loom.html

jnwatson 6y ago

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()); } ... } ...