Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>According to a post by Stephen Toub (MSFT), they are assuming that we are going to rely on closures to pass state data. There was also some excuse about signature ambiguity. (<a href="http://social.msdn.microsoft.com/Forums/en/parallelextensions/thread/1988294c-de41-476a-a104-aa550b7409f5" rel="nofollow">http://social.msdn.microsoft.com/Forums/en/parallelextensions/thread/1988294c-de41-476a-a104-aa550b7409f5</a>)</p> <p>However, relying on closures to solve this problem seems like a temporary hack waiting for a better solution. It works, but it's not a good longer-term solution. There are many times that simply specifying a delegate method as the action would be the simplest approach, but that means we have to use global vars or we're excluded from state parameter passing.</p> <p>I like one of Hugo's proposals (from the MS forum posting). Hugo suggested introducing a TaskState type, which seems like a clever way to circumvent the generics ambiguity issue.</p> <p>Applying this to the Task.Factory.StartNew() signature and the Task() constructor as such:</p> <pre><code> public Task&lt;T&gt;( Action&lt;T&gt; function, TaskState&lt;T&gt; state ); public Task&lt;T,TResult&gt;( Func&lt;T,TResult&gt; function, TaskState&lt;T&gt; state ); </code></pre> <p>ActionState would be a lot like the Nullable class -- just a simple wrapper around a Value member. In practice, using TaskState might look like this:</p> <pre><code> var myTask = new Task( MyMethod, new TaskState( stateInfo ) ); ... public void MyMethod( StateInfo stateInfo ) { ... } </code></pre> <p>The TaskState&lt;> solution is not perfect, but it seems like a much better solution than relying on closure of type casting.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload