Wanting a MS supported co-routine API in the frameworks

  • Article

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.