You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we keep track of all scopes that have ever been created. This is bad news bears for memory management.
It tends to work well in situations like a Jupyter notebook where the process is relatively short-lived (and Jupyter has it's own memory issues as well because it keeps track of every single output until the end of time), but less well for things like a webserver.
The underlying issue is that we're never sure when a frontend has a reference to a scope (any frontend could issue a setup scope command for any scope that might have used to exist - eg. after reconnecting to wifi). In the case of Mux, we would just have the client refresh so it's not that big of an issue.
Proposal
Implement a timeout system for purging scopes (e.g. if a scope hasn't been connected to in ten minutes, delete it). This must be configurable and probably should default to ever expiring since that's the current behavior. We also should also implement a way for the browser to tell Julia that it's done with a scope (this should be a second/separate PR).
We'd also need some kind of liveness probe for all of the active connections (maybe - the TCP connection dropping might be good enough for us to get a signal from?). We just don't want zombie connections to keep scopes persisted.
This would also WebIO-built things to be a bit more general purpose (e.g. internal web interfaces). I'm still not comfortable with writing public facing products using WebIO but this would better enable a certain use case.
Steps
Make global_scope_registry values weakly held
Add a dict from a connection to a set all of its scopes, remove the entry when the connection ends.
Are we currently handling connection endings?
Add browser->Julia command to disconnect a connection from a scope
The text was updated successfully, but these errors were encountered:
Think the best thing to do is have a WeakRefDict from connections to scopes and make the global_scope_dict entries WeakRefs as well. This should allow scopes to be GC'd by Julia when the connections go away.
We need a way to make sure that IJulia can hold on to the references forever though (maybe a callback that can be registered for whenever a Scope is constructed).
Optionally, we could implement a way to ping the connection from Julia and make sure it's still alive. This might not be necessary.
Currently, we keep track of all scopes that have ever been created. This is bad news bears for memory management.
It tends to work well in situations like a Jupyter notebook where the process is relatively short-lived (and Jupyter has it's own memory issues as well because it keeps track of every single output until the end of time), but less well for things like a webserver.
The underlying issue is that we're never sure when a frontend has a reference to a scope (any frontend could issue a setup scope command for any scope that might have used to exist - eg. after reconnecting to wifi). In the case of Mux, we would just have the client refresh so it's not that big of an issue.
Proposal
Implement a timeout system for purging scopes (e.g. if a scope hasn't been connected to in ten minutes, delete it). This must be configurable and probably should default to ever expiring since that's the current behavior. We also should also implement a way for the browser to tell Julia that it's done with a scope (this should be a second/separate PR).
We'd also need some kind of liveness probe for all of the active connections (maybe - the TCP connection dropping might be good enough for us to get a signal from?). We just don't want zombie connections to keep scopes persisted.
This would also WebIO-built things to be a bit more general purpose (e.g. internal web interfaces). I'm still not comfortable with writing public facing products using WebIO but this would better enable a certain use case.
Steps
global_scope_registry
values weakly heldThe text was updated successfully, but these errors were encountered: