[External] : Re: : Re: Project Loom VirtualThreads hang

[Ron Pressler]

> On 6 Jan 2023, at 18:50, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> I didn’t say it wasn’t possible - I’m saying forcing the designer to figure out “this runs here and that runs there” has scalability problems for large systems (not microsevices).

I think what you’re saying is that you’re *hypothesising* that needing to submit a video encoding task to the video encoding ExecutorService *could* be a problem, not that it is one, although it is certainly no harder than what you said you’d do anyway with platform threads: submit different tasks to different ExecutorServices. 

So to be even more precise, what you’re saying is that you wish virtual threads could improve the situation for video encoding tasks to be better than the situation today. Maybe that’s possible, but to do that we’ll need to actually see such services and study their particular needs, and because more people are asking to use virtual threads for transaction processing than for video encoding, we’re prioritising their needs. But again, if you run into a problem, even with your video encoding service — please report it.

> Having better support in vthreads would be great - but certainly not required. 


It would be great only under the assumption that better support for video encoding in the default virtual-thread scheduler will not harm its transaction processing performance, but one of the reasons why we can improve on scheduling in the first place is that we can optimise our scheduler for transaction processing, whereas the kernel scheduler needs to be a general compromise for very different kinds of tasks.

Of course, custom schedulers — which are on the roadmap — could be used here, but you’d still need to assign different kinds threads to different schedulers/ExecutorServices, just as you may need to do today with either platform or virtual threads.

— Ron