[External] : Re: Native interop with Virtual Threads

Robert Engels rengels at ix.netcom.com
Tue Jun 27 11:58:48 UTC 2023


See https://dave.cheney.net/tag/gomaxprocs and GOMAXPROCS. I’m sure there are other sources. It is a thoroughly discussed aspect of using CGO. 

> On Jun 27, 2023, at 6:18 AM, Danish Nawab <dnawab at outlook.com> wrote:
> 
> 
> > Go also locks the carrier thread in this arbitrary native case - and simply spawns a new one if needed.
> 
> Do you have a source for this information? I would like to develop an understanding of the similarities/differences between the two implementations. 
> From: Robert Engels <rengels at ix.netcom.com>
> Sent: Monday, June 26, 2023 4:11 PM
> To: Ron Pressler <ron.pressler at oracle.com>
> Cc: Danish Nawab <dnawab at outlook.com>; loom-dev at openjdk.org <loom-dev at openjdk.org>
> Subject: Re: [External] : Re: Native interop with Virtual Threads
>  
> Go also locks the carrier thread in this arbitrary native case - and simply spawns a new one if needed.
> 
> > On Jun 26, 2023, at 6:02 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> > 
> > 
> > 
> >> On 26 Jun 2023, at 17:45, Danish Nawab <dnawab at outlook.com> wrote:
> >> 
> >> Thanks Ron. 
> >> 
> >> What about native code that doesn’t make an upcall but does a blocking operation directly (via OS syscalls or similar)? Are such cases also rare? 
> > 
> > Yes. But supporting those — even if there was reason to — would have been even harder, as Java has no control or knowledge over what native code does.
> > 
> >> 
> >> What would be the advice if someone is making blocking calls from their downcalls? It might not always be possible to rewrite it in Java. 
> > 
> > If those operations are both frequent and lengthy, they shouldn’t be done on virtual threads.
> > 
> > — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230627/4b153a80/attachment.htm>


More information about the loom-dev mailing list