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

[Alex Otenko]

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> 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> 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> 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/20220908/5a678067/attachment.htm>