How hard would it be to make CancellationToken remotable?

[jnm2]

CancellationToken can't currently be serialized when remoting. If I understand correctly it would be serializable if its reference to CancellationTokenSource was marshalable, for example if CancellationTokenSource derived from MarshalByRefObject.

That makes typical async API patterns unusable with remoting. My use case is sandboxing plugins to a partially trusted AppDomain. The plugins have methods that do I/O and take CancellationTokens just like any other framework I/O API. The plugins themselves derive from MarshalByRefObject, but any attempt to call a method that takes a CancellationToken parameter fails.

There are use cases and workarounds in this StackOverflow question and others like it.
One solution appears to solve this problem the way I would have expected an ideal CancellationTokenSource to solve it.

In the meantime I could use the workaround class from the linked question. I'd have to choose between littering my interfaces with the workaround CTS types or writing a pair of facades for every interface to hide the fact that I'm using a remoting workaround. So because I appreciate elegant, dry code, and it's such a commonly used type, I'm wondering if there is any good reason not to make CancellationTokenSource marshalable?

[stephentoub]

I'm wondering if there is any good reason not to make CancellationTokenSource marshalable?

I think a big reason not to do this is cost. I ran some simple tests, and changing CancellationTokenSource to derive from MarshalByRefObject approximately triples the cost of instantiating a CTS (without any remoting in the picture), and even for use case that's more involved, e.g. canceling the source, the impact over the lifetime of the instance was still non-trivial, in this example ~33%.

All else equal, I agree it would be very nice if CancellationToken/CancellationTokenSource could be marshaled across remoting boundaries, but I don't believe it's worth the negative impact on the primary use case (non-remoting), especially since there is a workaround.

[jnm2]

Thank you for looking into this. You're right, with that kind of performance hit CancellationTokenSource should not derive from MarshalByRefObject.

Is there a chance that the remoting system could make a special case for CancellationToken and marshal the cancel event internally? The special case would be merited for the fundamental part it plays in best practice async API. That would make CancellationToken usable with marshaled calls, incurring zero perf hit when remoting is out of the picture.

[stephentoub]

Is there a chance that the remoting system could make a special case for CancellationToken and marshal the cancel event internally?

Anything's possible 😉, but I expect it would be a lot of work and complication for not that much gain. @jkotas may be able to offer more insights.

[jkotas]

I agree with @stephentoub assessment.

Remoting is not part of .NET Core that this repo is about. I am closing this issue because it is not actionable in this repo.