Native methods and virtual threads

[Maurizio Cimadamore]

I think API-wise, this is easy to do. Could become (as you say) a no-op 
in the future (or changed to implement the best practice "du jour"), or 
even be deprecated if no longer needed.

But the point that Alan and Ron are making is that it would be perhaps a 
bit more cautious to wait and see how big of an issue this turns out to 
be in practice, rather than pre-emptively changing the Linker API.

So, perhaps let's wait some time and reassess the situation? Stuff like 
this can always be added to the FFM API compatibly, if required.

Maurizio

On 14/07/2023 15:25, Brian S O'Neill wrote:
> One workaround is to pass messages through a special queue, where one 
> side is driven by a pool of platform threads, but this adds complexity 
> and overhead. I'm proposing a linker option hint. The hint might 
> utilize the Blocker class, or might automatically set up a messaging 
> passing queue if it makes more sense. Or it might be ignored entirely 
> if at some point stacks with native threads can be unpinned.