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
Eric Maupin suggested that he might be passing the same RpcMarshalable object across the same RPC connection multiple times. That is, the creator of the real object sends it as a method argument to several methods.
This pattern concerns me, because if the methods run concurrently I think JsonRpc will see the same object reference and store it only once in our marshalable object handle table, and reuse the same handle each time the object appears. On the receiving side, it will see the same handle each time and use the same proxy. Given the docs require the receiver to dispose of a marshalable object, each of these several methods will presumably dispose the object when they are done. But the first method to do this may end up removing the handle from the marshalable tables kept by both sides, zombifying the other proxies.
If so, this behavior is by design. But we should verify that our docs make abundantly clear that when an RpcMarshalable object is sent over RPC, the sender should truly consider that they don't own the object any more and should certainly not send it again.
Let's review the docs and possibly write a test for this scenario.
The text was updated successfully, but these errors were encountered:
Eric Maupin suggested that he might be passing the same RpcMarshalable object across the same RPC connection multiple times. That is, the creator of the real object sends it as a method argument to several methods.
This pattern concerns me, because if the methods run concurrently I think JsonRpc will see the same object reference and store it only once in our marshalable object handle table, and reuse the same handle each time the object appears. On the receiving side, it will see the same handle each time and use the same proxy. Given the docs require the receiver to dispose of a marshalable object, each of these several methods will presumably dispose the object when they are done. But the first method to do this may end up removing the handle from the marshalable tables kept by both sides, zombifying the other proxies.
If so, this behavior is by design. But we should verify that our docs make abundantly clear that when an RpcMarshalable object is sent over RPC, the sender should truly consider that they don't own the object any more and should certainly not send it again.
Let's review the docs and possibly write a test for this scenario.
The text was updated successfully, but these errors were encountered: