Fiber mode is gone...
Well, now that our RTM and RC-esque builds are starting to make it out into the wild it seems like a good time to discuss a feature we had to make go away...
That feature which most readers of my blog are probably now familiar with is fiber mode. So why did we cut fiber mode for the released version of the product? And what changes will you see because of this?
We had gone through great efforts to make sure that all of our core functionality worked great inside of a fiber mode host. Not only did the CLR team do a lot of work to make sure fiber mode was solid, but so did many other teams who picked up our toolset and verified that worked properly by running their tests inside of fiber mode. Not to mention the teams that typically run their tests inside of Yukon who also make sure their features work in fiber mode. We even spent extra time at the end of beta 2 to make sure we got all the last minute fiber bugs fixed from our full fiber mode test pass - but ultimately it wasn't enough.
In the end we had one final exit criteria we'd have to pass in order to make sure fiber mode was solid: Stress. Between the choices of spending our time fixing the bugs that we knew ALL of our customers would hit in thread mode, or fixing the bugs that a small percentage of users would hit in fiber mode, we picked fixing thread mode bugs. In the end I think most customers will be happy as the SQL and CLR teams came together and we've spent a huge amount of time, resources and effort ensuring that SQL/CLR works great under thread mode.
For those of you wanting to develop a fiber mode CLR solution I think you need to first ask yourself why you're doing this. If you're attempting to conserve stack space then this is not the solution you're looking for. If you're attempting to reduce the number of context switches experienced then you can still get much the same results using thread mode and blocking "switched out" tasks on an event that gets signaled when it's their turn to run. And of course there's a 3rd, although usually less desirable, option to redesign the way you're approaching the problem of a large number of work items.
Finally what are the changes in removing fiber mode? Surprisingly everything will work exactly the same as it did in pre-RC and RTM builds except for one API will now return E_NOTIMPL. That one API is ICLRTask::SwitchOut. You still can do all the interesting stuff with integrating the CLR task management with your own environment, and you can still switch a logical task in on a thread that previously had another logical task running on it, but you can't switch out a logical task during the middle of its lifetime.
I realize removing this feature will cause some of you some pain but I hope you'll see that this was the right call for us to get a super stable Whidbey out the door in a reasonable timeframe.
Comments
Anonymous
March 29, 2007
re: This is CLR - マネージコードとアンマネージコードの連携は簡単ではないAnonymous
May 18, 2008
This has been discussed fairly frequently on the Web. Chris Brumme discusses this here: http://blogs.msdn.com/cbrumme/archive/2003/04/15/51351.aspxAnonymous
September 08, 2008
In the previous day we saw what would happen underneath when we create a managed thread and how it maps