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
When a client queries func(), it receives a netref to the dictionary that is supposed to exist at the server side.
However, at the server side, the dict value has already gone out of scope after exposed_func() returns, and is thus eligible for being garbage collected.
How does the server-side ensure that the value returned by exposed_func() still exists for the netref to be valid? Who takes ownership (and manages the lifetime of) the dict returned by the exposed_func()?
The text was updated successfully, but these errors were encountered:
Okay I studied the source code for a bit, how this works is clever...
The Connection (aka Protocol) keeps references to objects that are returned over the link in its _local_objects attribute. These are subject to explicit reference counting, and when the remote side del's its netref, this is propagated over the line, leading to a decrease in the refcount. Once this hits zero, the object reference is removed from the _local_objects collection.
A mildly terrifying control flow for the lifetime management, but it seems to work :-)
Perhaps it is useful to mention this "live netref"-counting behavior in the docs somewhere; it demystifies what's going on.
Hello,
Suppose I have the following server:
When a client queries
func()
, it receives a netref to the dictionary that is supposed to exist at the server side.However, at the server side, the dict value has already gone out of scope after
exposed_func()
returns, and is thus eligible for being garbage collected.How does the server-side ensure that the value returned by
exposed_func()
still exists for thenetref
to be valid? Who takes ownership (and manages the lifetime of) the dict returned by theexposed_func()
?The text was updated successfully, but these errors were encountered: