C#中使用迭代器处理等待任务(3)


这里有一些好东西,事实上它真的有用,只要不触及用户界面:
它准确的返回了一个TaskCompletionSource的Task,并且通过源代码设置了完成状态。

    它显示了我们怎么通过迭代器的最后一个任务设置task的最终Result,同时避免可能没有结果的情况。

    它从迭代器中捕获异常并设置Canceled或Faulted状态. 它也传播枚举的task状态 (这里是通过Wait(),该方法可能抛出一个包装了cancellation或fault的异常的集合).

但这里有些主要的问题。最严重的是:

    由于迭代器需要实现“异步态的”的诺言,当它从一个UI线程初始化以后,迭代器的方法将能访问UI控件。你能发现这里的foreach循环都是运行在后台;从那个时刻开始不要触摸UI!这种方法没有顾及SynchronizationContext。

     在UI之外我们也有麻烦。我们可能想制造大量大量的由SLAM实现的并行运行的Tasks。但是看看循环中的Wait()!当等待一个嵌套task时,可能远程需要一个很长的时间完成,我们会挂起一个线程。我们面临线程池的线程资源枯竭的情况。

    这种解包Aggregate异常的方法是不太自然的。我们需要捕获并传播它的完成状态而不抛出异常。

    有时SLAM可以立刻决定它的完成状态。那种情形下,C#5的async可以异步并且有效的操作。这里我们总是计划了一个后台task,因此失去了那种可能。

是需要想点办法的时候了!

连续循环

最大的想法是直接从迭代器中获取其所产生的第一个任务。 我们创建了一个延续,使其在完成时能够检查任务的状态并且(如果成功的话)能接收下一个任务和创建另一个延续直至其结束。(如果没有,即迭代器没有需要完成的需求。)


// 很牛逼,但是我们还没有。 public static Task<TResult> ToTask<TResult>(this IEnumerable<Task> tasks) { var taskScheduler = SynchronizationContext.Current == null ? TaskScheduler.Default : TaskScheduler.FromCurrentSynchronizationContext(); var tcs = new TaskCompletionSource<TResult>(); var taskEnumerator = tasks.GetEnumerator(); if (!taskEnumerator.MoveNext()) { tcs.SetResult(default(TResult)); return tcs.Task; } taskEnumerator.Current.ContinueWith( t => ToTaskDoOneStep(taskEnumerator, taskScheduler, tcs, t), taskScheduler); return tcs.Task; } private static void ToTaskDoOneStep<TResult>( IEnumerator<Task> taskEnumerator, TaskScheduler taskScheduler, TaskCompletionSource<TResult> tcs, Task completedTask) { var status = completedTask.Status; if (status == TaskStatus.Canceled) { tcs.SetCanceled(); } else if (status == TaskStatus.Faulted) { tcs.SetException(completedTask.Exception); } else if (!taskEnumerator.MoveNext()) { // 设置最后任务返回的结果,直至无需结果为止。 tcs.SetResult( typeof(TResult) == typeof(VoidResult) ? default(TResult) : ((Task<TResult>) completedTask).Result); } else { taskEnumerator.Current.ContinueWith( t => ToTaskDoOneStep(taskEnumerator, taskScheduler, tcs, t), taskScheduler); } }

这里有许多值得分享的:


    我们的后续部分(continuations)使用涉及SynchronizationContext的TaskScheduler,如果有的话。这使得我们的迭代器在UI线程初始化以后,立刻或者在一个继续点被调用,去访问UI控件。
    进程不中断的运行,因此没有线程挂起等待!顺便说一下,在ToTaskDoOneStep()中对自身的调用不是递归调用;它是在taskEnumerator.Currenttask结束后调用的匿名函数,当前活动在调用ContinueWith()几乎立刻退出,它完全独立于后续部分。
    此外,我们在继续点中验证每个嵌套task的状态,不是检查一个预测值。


然而,这儿至少有一个大问题和一些小一点的问题。

如果迭代器抛出一个未处理异常,或者抛出OperationCanceledException而取消,我们没有处理它或设置主task的状态。这是我们以前曾经做过的但在此版本丢失了。
    为了修复问题1,我们不得不在两个方法中调用MoveNext()的地方引入同样的异常处理机制。即使是现在,两个方法中都有一样的后续部分建立。我们违背了“不要重复你自己”的信条。

如果异步方法被期望给出一个结果,但是迭代器没有提供就退出了会怎么样呢?或者它最后的task是错误的类型呢?第一种情形下,我们默默返回默认的结果类型;第二种情形,我们抛出一个未处理的InvalidCastException,主task永远不会到达结束状态!我们的程序将永久的挂起。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wgdgsx.html