You do not have the context switching overhead in Fibers.... Given that you handle the 
switching cleanly in your own code you get a big benefit when the load increases.
Fibers via interop are tempting but the potential for side effects using Fibers is 
significant if you are the first person trying it and you have the interop overhead 
too. If there is a wrapper for this due out that would be nice, or if someone knows of 
a successful implementation that would be nice too. Does anyone know of either of 
these?

Thanks for you input guys, much appreciated.
Gavan

-----Original Message-----
From: Jim Arnold [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 19, 2002 11: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.

Reply via email to