audit unload

[ens-ds23]

No description provided.

[azangru]

I'll be interested in an explicit handle exposed to the javascript side, which we can call when we are removing the DOM element that we have given the genome browser to control.

[ens-ds23]

The difficult bit will be "finding all the things" to delete. In most cases with boring, run-of-the-mill allocations, this will happen automatically but in some (mainly browser APIs, like WebGL, listeners, etc), you need to actually do something to avoid a leak. So I don't expect memory to be the long-term issue but some fancy limited resource we don't know about like "maximum number of canvases" or something unknown-unknown like that. Once all that is managed properly it can be wired into both an explicit external call and, if necessary, to any listeners (eg to stop parting errors after a user navigates away using the web browser's nav bar). This unloading can then be made idempotent with a "dead-is-dead" flag at the top level, y'know a kind of if(global.!dead) { global.dead=true; do_dead(); } type of thing (not actual code!).

[azangru]

In the javascript land, if you unset all references from the objects that survive the cleanup to the DOM nodes that are no longer needed (by setting object properties referencing those nodes, or functions that could have captured those nodes in their closures, to null), the garbage collector will clean up these nodes from the memory. Since webassembly, as far as I understand, isn't yet capable of referencing DOM nodes directly, your cleanup logic will likely be focused on the javascript code that handles the DOM and sets up listeners.

[ens-ds23]

A bigger issue is things which remain shared after they've passed over the API in one direction or another. Rust has to keep handles to things which it may need, which map to a reference somewhere deep down in the wasm glue, and when it knows everything has dropped the handle, it can release that reference as well, which the gc on the js side can see (it just looks like another reference).

The problem is that if js also needs to keep a reference, then the js will never garbage collect because Rust has a reference and the Rust can't drop its reference because it can't tell whether js has dropped its reference (or might surprise rust by calling it all of a sudden!). That's only really a problem for things like callbacks where the js can spring a surprise and jump into that code. For things like DOM nodes rust can just drop (if it no longer needs it) as you say, but listeners and callbacks take more care because of the "shared interest". Fortunately it's a very small bit of the code that needs to care (a few hundred lines in total). It's not a major, complex issue, you just need to make sure you unregister etc first, but it does require care from the programmer (which is never a good thing!).

I suspect (hope!) #19 is an "already abandoned thread falls into bear trap and crashes" type bug, but I will check and ideally stop the error as well.