I remember following Dino's cooperative fiber mode posts and remarks on sample code last year with great interest, and was eager to try this out in some of the later versions of SQL Server 2005. For me, it was only a curiosity -- I have never had or seen the need to write a fiber mode SQLCLR procedure. The SQL and CLR teams decided it was more important to make sure normal threading issues were rock solid for ALL operation rather than pay half-attention to both regular threading AND fiber mode issues that may benefit a few. The biggest obstacle for fiber mode sign-off was dealing with stress conditions. It's an understandable choice -- I would much rather have the basics to be rock solid. Dino does bring up an interesting point regarding use of fiber mode in your application design:
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.
Again, I am glad the teams focused on the items that could be made feature complete. I wonder, though, how many people/companies this will impact in their anticipated design after rollout?