-
Notifications
You must be signed in to change notification settings - Fork 146
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
IDisposable interface ambiguity on receiver side when marshaling with RpcMarshalableAttribute #931
Comments
Thanks for the excellent explanation and for proposing a fix.
This is not supported today. You should consider that any object marshaled across RPC is now 'owned' by the receiver.
Your proposal would be a breaking change at this point. You've obviously given this a lot of thought. Thank you. I'd be interested in continuing to brainstorm on a solution to this with you. What if we take a variant of your idea: Allow for any marshaled object to derive from either Thoughts? |
Summary
This is an issue related to the RpcMarshalableAttribute which is proposed in #774 and merged in #777
According to my understanding, the
IDisposable
interface is ambiguous on the receiver side when marshaling with RpcMarshalableAttribute.Example
Let's think of a scenario that the
ITest
interface should be marshaled instead of serialized.The RPC server (sender):
And the RPC client (receiver) uses it as:
Problem
RpcMarshalableAttribute
required the marshaled interface to derive fromIDisposable
interface (to dispose the proxy?).It seems to me that, the
Dispose()
method called on the receiver side would cause two things to happen:handle
as disposed, and the sender side removes the corresponding Object out of context.IDisposable.Dispose()
on the original object on the sender side.So, calling
Dispose()
method on the receiver side is rather ambiguous.Sometimes we only want to dispose the proxy on receiver side without disposing the original object on sender side. However, I don't know how to achieve this.
Probable Solution?
How about defining a dedicated interface for marshaling like this:
And require any interface to be marshaled derive from this interface:
The
IRpcMarshalable
interface has a default implementation ofDisposeProxy()
, which won't be overridden on the sender side.The receiver side proxy generate should override
DisposeProxy()
method to dispose theproxy
andhandle
in JsonRpc context.With this approach,
IDisposable
won't be a required interface to derive from, and the ambiguity disappears.Remind receiver to dispose proxies
In #774 (comment) concerned about to remind the receiver to dispose the proxies
Maybe we can write an Roslyn Code Analyzer to warn that these proxies should be disposed?
If this approach is acceptable, I would be happy to implement it and create a PR.
The text was updated successfully, but these errors were encountered: