[External] : Re: Native methods and virtual threads

[Ron Pressler]

If Blocker were optimal then Executors.newCachedThreadPool() would have been optimal and we wouldn’t have needed virtual threads. It can only potentially work when the operation is infrequent but not too infrequent to not matter. In the case of filesystem access we had no choice because we could offer no alternative, so we have this as a (hopefully temporary) stopgap measure that’s an internal implementation detail. How important it is to design an API for it is something we’ll need to learn.

— Ron

> On 14 Jul 2023, at 13:39, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> 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