[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