[External] : Re: Native interop with Virtual Threads

[Robert Engels]

Actually the docs here https://tip.golang.org/src/runtime/cgocall.go is the definitive source.  

> On Jun 27, 2023, at 6:59 AM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> 
> 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/baf681ab/attachment-0001.htm>