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

[Alex Otenko]

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> wrote:

>
>
> > On 7 Sep 2022, at 09:05, Alex Otenko <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/76c1fe3a/attachment.htm>