News for hackers. Stuff that matters.
Re:Test for lists in Cython by zozbot234 on Monday April 19, 2021 @09:00AM (#26862245)
> This ... is how many gc:ed runtimes interact with other gc:ed runtimes.

It's not that easy. You'd need to register the object as a GC root as long as it's being managed by the foreign GC, and similarly ensure that objects in the foreign VM are properly "de-registered" when the local GC finalizes them. It's far from trivial, particularly when compared with other memory-management strategies.

Re:Test for lists in Cython by chalst on Monday April 19, 2021 @11:12AM (#26863605)
This is a solved problem: look at how the Lua FFI does it. Lua both is capable of exporting its own garbage collector to its counterparty and has a plug-in system for GC so that Lua can use the counterparty's GC. That allows you to either use Lua's GC for foreign objects or have the counterparty's GC manage Lua's objects.

It's funny the hostility to JIT that some fans of compiled languages have.

Re:Test for lists in Cython by bjourne on Monday April 19, 2021 @09:15AM (#26862383)
Yes, that is what the scheme I described is doing. You'd need a similar mechanism in Rust too to prevent it from collecting objects prematurely. I think implementing this is fairly trivial. The difficult part of writing an FFI is handling closures: Java calling Python calling Java calling Python which throws an exception...
Re:Test for lists in Cython by urschrei on Monday April 19, 2021 @09:05AM (#26862296)
Thanks – this is the more informed version of what I wrote.