Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The garbage collector thinks my object is garbage :( #1005

Open
joepie91 opened this issue Oct 11, 2023 · 1 comment
Open

The garbage collector thinks my object is garbage :( #1005

joepie91 opened this issue Oct 11, 2023 · 1 comment

Comments

@joepie91
Copy link

joepie91 commented Oct 11, 2023

I'm currently writing Neon bindings for Veilid, an overlay network written in Rust (and exposed as a Rust library), so that I can use this network from Node.

It uses its own internal event loop (Tokio, in this case), and allows specifying of a callback that is called for every update struct; this ranges from network status to received messages to configuration stanzas.

I've wired this up fairly 1:1 (don't mind the mess, etc.), so that you can likewise specify a JS callback, and it will be invoked for every update. This all works so far.

Now the problem is that fairly shortly after connecting, the core object gets garbage-collected, triggering the finalize that shuts down the connection (without this 'clean shutdown' implementation, things seem to break considerably more loudly when GC happens). I am currently preventing this by keeping a reference to it on the JS side in an interval, but that is of course a hack, and not a real long-term solution.

Unfortunately, I've been unable to find anything in the Neon API that lets me affect how the garbage collection works, and I can't say that I'm very experienced at Rust, so I'm stumped on how to solve this 'properly', and there doesn't seem to be much documentation on dealing with the JS GC from Neon. What would be the best way to approach this with Neon?

@kjvalencik
Copy link
Member

kjvalencik commented Oct 11, 2023

Neat project! It would also work to leave the variable in a global scope in JS where it could still be referenced--this is how I would probably do it.

If the intent is that core never gets dropped (it's a permanent global), you can also accomplish this by leaking a reference to it on the Rust side.

Root is a Rust handle to a JavaScript object. As long as the Root exists, the value won't be garbage collected. Any Rust method for leaking variables should work.

For example, putting it in a global static with OnceCell or Box::leak.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants