It is more an issue of whether you can schedule the work to be done better than the OS. If you have say 5 things to do you could either let the OS schedule them for you (threads) or you could schedule what gets worked on (fibers).
Kevin -----Original Message----- From: Jim Arnold [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 10:46 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Green thread support I'll take your word for it. Actually, no I won't :-) Why *would* fibers be any more scalable/available than threads? I don't see how splitting an already interruptible thread into yet more mini-threads would give you anything but more interruptions. Jim (who knows SFA about threads and is liable to get his ass kicked) > -----Original Message----- > From: Brad Wilson [mailto:[EMAIL PROTECTED]] > Sent: 19 April 2002 16:29 > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] Green thread support > > > Jim Arnold wrote: > > > I don't know that such 'virtual' threads would have any > advantage over > > native threads (if threads are available on the target > platform) other > > than avoiding a context switch. > > I disagree. The use of user-controlled threads on the Win32 platform > (fibers) can lead to some incredibly high > scalability/availability apps, if > you know how to use them properly. > > Brad > > -- > Read my web log at http://www.quality.nu/dotnetguy/ > > You can read messages from the DOTNET archive, unsubscribe > from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
