> > I'll take your word for it. Actually, no I won't :-) Why > > *would* fibers be any more scalable/available than threads? > > Primarily because you can control the scheduling of your own > work items > around completion. The server versions of the OS attempt to > "help" you in > this regard by giving you a very large quanta (about 10x as > large as the > workstation OSes, IIRC), but that's still no good if you're just a few > milliseconds from fulfilling a request, only to be cut off by the OS.
So how do you stop the OS messing with your schedule by simply blocking the entire thread? I'm guessing the use of fibers or threads is mutually exlusive within a single process. Anyhow, while I go and join comp.programming.threads, here's something I found in the archives that might answer the original question: "... in general, we don't want to encourage people to obtain the ThreadId of a thread because it limits our ability in the future to break the 1:1 correspondence between managed threads and OS threads (e.g. implementing fibers in the runtime)." - Brad Abrams, Microsoft. Jim You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
