Wanting a MS supported co-routine API in the frameworks

Sigh… Apperantly I have serious problems and I should be getting myself some help post haste :-). At least according to Steve and Gregg I do. They’re two debugger devs and they gave me the following legitimate advice when I said I wanted to dable in some undocumented APIs for dealing with fibers and the runtime:

  • Cyrus, I think we need to stage an intervention. Using Fibers here is nothing but crack smoking crazy
  • Don’t even think about doing this. I can’t believe that MSDN published this article. Don’t use Fibers.
  • Wail in agony as you find the debugger doesn’t work.

Gregg raised some other concerns; specfically:

  • Will the next owner of this code be able to understand this?
  • How difficult will this code be to debug?
  • How difficult would it be to support this code after the product ships?

I thought I’d try to address these points and explain what I’m really interested in in the end. First of all, I definitely wasn’t advocating using Fibers through and through your code base. I was just trying to accomplish the task of implementing a coroutines API simply (for both me and the API consumer). As many people who gave feedback realized, it just didn’t seem possible without the ability to save the current state of the system inside a method and then resume it at some later point. Fibers seemed to provide that ability quite nicely. Also, from the consumer persepctive they only exposed ‘Yield’ and ‘Resume’ but not any actual fiber manipulation routines.

Second of all, I’ve never used the debugger for managed code before. Well, that’s not true. I used the debugger exactly one time in my life while I was writing some raytracing code and I needed to get some information out after the program had run for millions of cycles already. I’m not sure what it is, but I just don’t find it that useful with the programs I write.

It’s true that the next owner of this API would probably find it incredibly confusing. However, there would be so serious documenting going along with it, as well as pointers to the Fibers APIs I’d be using. There would also be extensive unit tests to verify the behavior and to show what we expected to happen.

The points about debugging seem pretty unreasonable to me. If, after calling Resume/Yield the debugger doesn’t switch to the appropriate location, then that seems more like a debugger issue to me 🙂

All I am looking for here is an API that allows me to create to save the state of execution at any point and then return to that in the future. If fibers aren’t the way to do that, then give me something that will. Make it a nice supported API written by people who know the runtime well and understand all the pesky issues involved so that I won’t run into a situation where 3 days before shipping a product some heinous bug becomes apperant. Luckily, that wish might be granted:

Dino wrote on Gregg’s blog: “I’ll point out that we’re planning (as always everything can change) on shipping an SDK sample in Whidbey that allows you to do managed co-routines using the Whidbey hosting APIs. I would also strongly recommend that you only pursue fibers on Whidbey (if anywhere).”

That sounds fantastic Dino! Could you keep us informed of the progress in this area? There are a lot of conceptually simple, very powerful, tasks that are unfortunately quite difficult to accomplish currently without these APIs. With the addition of anonymous delegates to C# and generics to the whole framework I’m feeling like it’s almost possible to do everything i used to be able to do in functional languages. Having support for coroutines would remove this one area where it still feels like there a disjoint in expressive power.

Comments (5)

  1. First, now I need to learn about coroutines.

    Second, alright, I’ll bite.

    What process do you use that makes using the debugger irrelevant?

    Even when I did a project from start to finish with TDD, I still found myself firing up the debugger a few times.


  2. D. Brian Ellis says:

    I’m also interested in exactly what you do that never requires the debugger. I would love to say "Oh I just fire up Notepad and put a few cout statements in there…" but those days are long gone. I end up with a lot of debugger action these days. Breakpoints are your friend.


  3. Actually… I can see how its possible to end up not using the debugger that often. I find myself using it less and less as I do more and more unit testing. When you do good unit testing early, you find that your unit tests expose the bugs in your code in very obvious ways, very early. So when a test fails, you end up not even needing to debug it to figure out what went wrong. You just slap your forehead… say "Doh, That was stupid"… and fix the problem.

  4. A while back there was an article in MSDN magazine about wrapping up the unmaged fibers API to implement…