[External] : Re: Can continuation support finally solve the "How do I stop this thread" problem?

[Ron Pressler]

1. Those are best practices for *platform* threads, which are expensive and often shared. Virtual threads have a different set of best practices. To get a sense for them, think of virtual threads as simply a representation of a task. We don't have task-pools, so we don’t have virtual thread pools.

2. Semaphores work great — better than pools — and it’s trivial to wrap the thread’s body with code that releases the semaphore. In fact, you can even do that in a trivial implementation of ThreadFactory and pass it to APIs intended for virtual threads, like Executors.newThreadPerTaskExecutor and StructuredTaskScope. Thread factories also compose nicely. E.g. here's a pretty sophisticated way to control thread creation with semaphores:

    ThreadFactory semaphoreThreadFactory(Semaphore s, ThreadFactory tf) {
      return r -> {
          try {
              s.acquire();
              return tf.newThread(() -> { try { r.run(); } finally { s.release(); }});
          } catch (InterruptedException e) { throw new RuntimeException(e); }
      };
  }

— Ron

On 7 Sep 2022, at 14:22, Alex Otenko <oleksandr.otenko at gmail.com<mailto:oleksandr.otenko at gmail.com>> wrote:

Well, threads are different. There are best practices that involve thread pools with pool size limits - not because we are mean, but because we want to be sure we detect runaway computations. With Virtual threads the suggestions sounded here were to not pool or reuse them. So we can't use the same technique. Semaphores also won't work, as someone would need to count down when the Virtual thread is done.

On Wed, 7 Sep 2022, 13:12 Ron Pressler, <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>> wrote:


> On 7 Sep 2022, at 09:05, Alex Otenko <oleksandr.otenko at gmail.com<mailto:oleksandr.otenko at gmail.com>> wrote:
>
> On a different but somewhat related note. What do we get when we can't create a new thread? I think we get an OOME.
>
> Is there a way to limit the number of Virtual threads platform-wide so we get an error that can be handled in some other way than trying to catch and analyze OOME?


No, just as there is no way to limit the number of Strings, ArrayLists, CompletableFutures or native byte buffers platform-wide — or platform threads for that matter. Threads are just objects, and virtual threads are objects that are more similar to Strings or CompletableFuture in their resource consumption than to platform threads or native buffers, so there’s also no reason to do that any more than for other kinds of objects. But you can monitor the number of Threads in the platform with MBeans (mostly because virtual threads are threads, and we provide that service for threads).

Creation of virtual threads can be controlled by the application using the mechanisms available today to control any kind of object (say, a semaphore).

— Ron



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220907/5dda33be/attachment-0001.htm>