9

I'm using TaskCompletionSource to provide and drive an instance of Task. I would like to be able to set the Task to status Running to indicate that the task is... 'running' however I can't see a way to achieve this via TaskCompletionSource.

Is there a way to do this?

mackenir
  • 10,801
  • 16
  • 68
  • 100
  • Why do you want that? Why do you care about the status of the `Task`? – svick Feb 12 '13 at 17:49
  • 1
    Well, I'll turn that around and ask "why does Task have a Running Status?". Perhaps this status signals something different than the general idea that the task is running and so is inapplicable to a Task backed by TCS. If not I'd like to signal that the task is running (or 'something is happening') to consumers of the Task. – mackenir Feb 12 '13 at 17:57
  • ***TL;DR** You need to build a higher-level notification abstraction.* `Perhaps this status signals something different than the general idea that the task is running` I think that's pretty much it. The fact that you use `Task` is an implementation detail, and `TaskStatus` is there to support the *infrastructure* of the TPL, like chaining continuations and supporting task debugging (hence statuses like `WaitingForChildrenToComplete`). Ask yourself how you'd implement this if using pre-`Task` asynchronous methods, then adapt that to `Task` instead. APM provides no "Running" status, either. – anton.burger Feb 16 '13 at 12:21
  • 3
    In fact, I am adding Task support to an API. The idea of cooking up a custom abstraction on top of Task doesn't make much sense here. I suspect API clients would be saying "just give me a Task so your API is useful, not this abstraction you've come up with". The fact I'm using *TaskCompletionSource* is the implementation detail and this leaks out because of the limitations in TCS. – mackenir Apr 09 '13 at 12:57

1 Answers1

4

No. There isn't a way.

Whether or not you like my answer, however, it is the correct one. :-)

The following is my opinion, and an attempt to help you feel better.

Task.Status has several states that are only set and useful when the task is a scheduled task. Tasks from TaskCompletionSource are not scheduled tasks. The concept of WaitingToRun, Running, etc. are therefore not applicable in the traditional scheduled task sense. If you did have the ability to set these, you'd have to decide on what semantics to apply to these values, which may conflict with how others interpret them.

Ultimately, I don't think your code should ever make any decisions based on these intermediate states anyway. Doing so sounds like a "code smell".

Andrew Arnott
  • 80,040
  • 26
  • 132
  • 171
  • 4
    I disagree - why expose these states if they should never be used. If we're throwing around jargon, I smell a 'leaky abstraction'. ;-) Nonetheless, I reckon your answer is correct - 'there isn't a way'. Thanks – mackenir Apr 09 '13 at 12:52
  • 1
    It's not that they should *never* be used, so perhaps I used too strong of language. It's just very rare when they should be used. For example, if you're implementing a TaskScheduler, then they *might* be useful. I've written 10,000s of lines of code in TPL and I've only used these intermediate TaskStatus values a couple times. – Andrew Arnott Apr 27 '13 at 17:57
  • There is a way, which I posted in https://stackoverflow.com/a/68760628/2505186. but it's using Reflection. Not nice, but working. – Tobias Knauss Aug 13 '21 at 11:44
  • At the very least it might have been helpful to know what state the TCS Task is initially set to. I had to use the debugger to find it is the 'waitingForActivation' state. The TCS implementation could have held the Task in any condition prior to setResult being called. My first guess was that it set it to a Running state but the debugger showed me that was not the case. Then I tried 'start'ing the underlying task and was rewarded with a InvalidOperation exception. Finally I searched stack overflow to find the missing documentation. :) – Travis Sep 24 '21 at 17:27