Provide Better "Context" Support to Async Operations - by Jason Kresowaty

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


0
0
Sign in
to vote
ID 276325 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 5/8/2007 5:11:13 PM
Access Restriction Public

Description

Async methods commonly store state data in their class object or in the state object that is passed as a parameter.  It can be useful to be able to provide "out of band" data to the asynchronous routine and the callback routine beyond these mechanisms.

I have found that .NET provides a mechanism that "almost works" through the CallContext architecture.  The data must be set through the LogicalSetData method.  The problem is that such an object must be serializable, otherwise other things will break.  For example, if you uncomment the lines in the Problem Statement example, it will fail.

Clearly, however, it is not really necessary for the object to support serialization to be useful with asynchronous routines in the manner illustrated by the example.  This is a suggestion to provide a more suitable context specifically for use with asyncrounous routines that does not require the data value objects to be serializable.

(As a somewhat unrelated issue, LogicalSetData should probably fail right away if the object is not serializable, instead of waiting until an cross-AppDomain call finally happens.)
Sign in to post a comment.
Posted by Microsoft on 5/16/2007 at 2:05 PM
Thank you for you feedback. Using CallContext for scenarios that do not involve remoting should be probably regarded as a design flaw. There are more suitable (and more efficient) ways how to pass data to another thread in the same domain. The 'object' parameter of BeginInvoke is definitely the preferred solution in your example. Static fields will obviously also provide the desired functionality. The exception is thrown when an attempt to serialize the instance and pass it to another domain is actually made. This means that you can put non-serializable instances to CallContext as long as you do not cross the domain boundary. The fact that types generated by C# are not marked as serializable by default can be viewed as a hint that the cost associated with passing objects as 'hidden parameters' may not be trivial.

Please use the 'object' parameter of BeginInvoke or static fields if you need to pass additional information to asynchronous calls. No additional context needs to be provided by the .NET Framework. If for some reason a context with the same interface as CallContext is required (named slots etc.), it can be easily implemented by a user class using a static underlying store.

Thanks!
Ladi Prosek, CLR
Posted by Microsoft on 5/10/2007 at 1:01 AM
We have routed this suggestion to the appropriate group within the Visual Studio Product Team for triage and resolution.

Thank you,
Visual Studio Product Team.