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

[Ron Pressler]

Virtual threads make imposing such restrictions a lot *easier* than pools, as semaphores interact more cleanly. For example, suppose you want to restrict the number of concurrent DB requests to 10, but also have a cache, then you guard just the DB with the semaphore, and things are balanced automatically without juggling tasks from one pool to another.

— Ron


On 8 Sep 2022, at 09:18, Alex Otenko <oleksandr.otenko at gmail.com<mailto:oleksandr.otenko at gmail.com>> wrote:

1. We set a limit of, say, 100 not because we can't have 101 or 200, but because we need to draw a line somewhere, and say: if you are using 101, you are definitely doing something wrong.

Tasks also have pools - that's bounded queues. Again, we might set the limit of 16k, but that's not because we can't have 32k, but because if you have 16k+1, you are doing something wrong. (Your system is not coping, perhaps)

2. Agreed.

On Wed, 7 Sep 2022, 17:31 Ron Pressler, <ron.pressler at oracle.com<mailto:ron.pressler at oracle.com>> wrote:
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/20220908/6a97228e/attachment-0001.htm>