Ayend Rahien spotten my post on cooperative scheduling, and had a comment:

Cooperative threads relies on programmers' disipline to yield often enough to make sure that other threads are not starved. I can see several cases for doing this in SQL Server, since this can ensure that you'll not be pre-empted before you finished. I would guess that this is a good way to reduce locks in certain situation, since in this scenario you know that you will not be interrupted until you are ready. Windows 3.1 and Mac OS before X proved that this just doesn't work in the general case. A single ruoge application can take hold on the whole system.

Well, in Cincom Smalltalk, this model gives you predictability - you know exactly what a thread is going to do. The issue with runaway threads rarely comes up for a simple reason - most processes end up pausing for I/O (user input, db access, file access, sockets - what have you). That wait for I/O state is what prevents a problem from arising. Sure, if you create a CPU bound process, you can hose a system - I even blogged about that kind of issue here, in terms of a CPU bound process taking up too much time in this blog server.

What it looks like the SQL Server team spotted is something common to an awful lot of applications - CPU hogging is fairly rare, while processes getting into an I/O wait state are pretty common. As to worrying about thread management - I've worked with a lot of customer code, and I've dealt with application level threading extensively in Silt and BottomFeeder. With the exception of a few expensive operations in the Silt server, I've not had to devote a lot of thought to the problem. And even there, the problem had already been solved for me, by some Smalltalk library developer a long time ago.