[External] : Re: Executors.newVirtualThreadPerTaskScheduledExecutor() ?

[Ron Pressler]

> On 2 Aug 2023, at 14:47, Dr Heinz M. Kabutz <heinz at javaspecialists.eu> wrote:
> 
>>> On 2 Aug 2023, at 12:26, Dr Heinz M. Kabutz <heinz at javaspecialists.eu> wrote:
>>> 
>>> I've been doing this for a while (and am using the approach on my javaspecialists.eu website):
>>> Executors.newSingleThreadScheduledExecutor(
>>> Thread.ofVirtual().factory())
>>> 
>>> It works very well indeed.
>>> Regards
>>> 
>>> Heinz
>>> — 
>>> 
>> I would advise against that and in favour of the approach in the Stack Overflow answer. Remember that a virtual thread should normally only ever execute a single task that’s been submitted to an Executor. 
>> 
>> I understand that your intent is good, and that you probably just want to use the convenient “fixed rate” methods of ScheduledExecutorService to run what is *conceptually* a single task, but many of the problems we see with people misusing virtual threads and not getting good results are due to them not internalising this idea that a virtual thread is a single task, so I would suggest not to show this kind of usage to virtual thread beginners.
>> 
>> — Ron
>> 
> What about this use case for virtual threads?
>         Cleaner cleaner = Cleaner.create(Thread.ofVirtual().factory());
> (Not that I typically need Cleaners, but if I did, I wouldn't want a platform thread bound up just for that.)

Yes! In fact, we had to do some work to make that work, so that’s an intentional use-case.

> Could you perhaps expand a bit on the problems that are caused by my solution above?

There is no problem, and at least in one specific case I would say it’s perfectly valid: you have a single task that you want to run on a single thread at a fixed rate. I was commenting not on the approach but on suggesting it in public before people gain experience with virtual threads, i.e. the only “problem” is a pedagogical risk.

One of the questions I see coming up on social media over and over is “how many virtual threads do I need?” or “why would anyone ever need so many threads?” The thing we are trying to communicate to those encountering cheap threads for the first time is that even though they’re a familiar abstraction, the form factor requires a different kind of usage and, in fact, that is precisely where the benefit lies. Platform threads are viewed as a computational resource. Virtual threads, on the other hand, represent a domain object: a task. The question of “how many virtual threads do I need?” Is, therefore, similar to the question, “how many strings do I need to keep a list of active user named in memory?”. The answer, in both situations is, “as many as there are domain objects”, which, in the case of virtual threads means “as many as there are tasks.” Similarly, the answer to the second question of “why would anyone ever need so many threads?” is “because a virtual thread is a task, and we often need that many tasks.”

That is why I fear showing beginners, *at this early stage*, any usage that appears to use a single virtual thread to run multiple tasks. People should first get used to thinking “a virtual thread is a task” before considering exceptions such as, “in this particular case, scheduling some operation to run at a fixed rate is conceptually a single task.” So there’s nothing intrinsically wrong with your usage, it’s just something that should be shown after people have already internalised the proper way of thinking about virtual threads.

— Ron