Fibers, and other mad stuff that you shouldn’t use

  • Article

In Cyrus’s last post (https://blogs.msdn.com/cyrusn/archive/2004/06/07/149893.aspx) he wrote:

“...i got a great email from Neil pointing me to this article on fibers and coroutines in .Net“

I am not sure I can say this strongly enough. DON’T USE FIBERS IN A MANAGED APPLICATION. The 1.1/1.0 runtime will deadlock if you try to managed debug a managed application that used fibers. The CLR team did a lot of work for fiber support in the 2.0 runtime, but it still won't support debugging.  You should only use fibers if:

  • You are porting code that already uses a threading library (never true for managed code)
    -or-
  • You are writing a database, and are willing to devote years of dev time to trying to get the best performance possible.

Fibers are inherently painful to debug. Most code is not fiber safe because fibers don’t work with all of the normal thread synchronization code, or any code that uses thread local storage.

Too often, programs like to use some new fancy feature. When writing code, it is important to ask:

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

Fibers fail all of these tests.