<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
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.
<div class=""><br class="">
</div>
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class=""> <font face="Courier New" class="">ThreadFactory semaphoreThreadFactory(Semaphore s, ThreadFactory tf) {</font></div>
<font face="Courier New" class=""> return r -> {<br class="">
try {<br class="">
s.acquire();<br class="">
return tf.newThread(() -> { try { r.run(); } finally { s.release(); }});<br class="">
} catch (InterruptedException e) { throw new RuntimeException(e); }<br class="">
};<br class="">
}</font>
<div class=""><br class="">
</div>
<div class="">— Ron<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 7 Sep 2022, at 14:22, Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com" class="">oleksandr.otenko@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="auto" class="">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.</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 7 Sep 2022, 13:12 Ron Pressler, <<a href="mailto:ron.pressler@oracle.com" class="">ron.pressler@oracle.com</a>> wrote:<br class="">
</div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" class="gmail_quote">
<br class="">
<br class="">
> On 7 Sep 2022, at 09:05, Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com" target="_blank" rel="noreferrer" class="">oleksandr.otenko@gmail.com</a>> wrote:<br class="">
> <br class="">
> 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.<br class="">
> <br class="">
> 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?<br class="">
<br class="">
<br class="">
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).<br class="">
<br class="">
Creation of virtual threads can be controlled by the application using the mechanisms available today to control any kind of object (say, a semaphore).<br class="">
<br class="">
— Ron<br class="">
<br class="">
<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>