Native methods and virtual threads

[Robert Engels]

Why do you say that Blocker usage is non optimal. I think that when the common IO operations are VT “reworked” the remaining cases being handled by Blocker seems simple and reasonable. I think the Gos team experience with doing just this has proven to be sufficient if not optimal (in lowering runtime complexity). 

> On Jul 14, 2023, at 3:14 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 13/07/2023 23:11, Ron Pressler wrote:
>> Blocker is not a user facing construct, but an implementation detail that offers non-ideal behaviour when that’s the best we can do. Obviously we’d like to eventually replace its use with better solutions where possible.
>> 
>> Offering something similar outside the JDK may well be something we’ll do once we learn more about virtual thread usage in the field. There are other virtual-thread-related capabilities that are currently only available inside the JDK because we don’t yet know how to prioritise their design as an API.
>> 
>> Anyway, your suggestion is certainly an idea to consider if and when the matter of blocking native calls rises in the priority queue. Of course, this is just my perspective and not necessarily that of the Panama team.
>> 
> Just to add that this also interacts with other exploration into custom schedulers and notifications that an operations may block indefinitely. Custom schedulers potentially means executing arbitrary code at sensitive times and will need taming. A linker option that is on the opposite end of the spectrum to "trivial" may have to interact with custom schedulers so something to examine when this topic bubbles up to the priority queue.
> 
> -Alan