I have my appliction hosting the MS CLR and running fibers. Works fine. I simply use threads when I need managed debugging - VS.NET can't debug across the COM call to make the MS CLR aware of the fiber switch (both 2003 and 2005). Of course, the performance benefit of threads is noticable - simply switching between 800 threads takes ~8ms on a 3+Ghz cpu, while the same number of fibers only take ~1ms.
I'm guessing the TLS that Mono uses is what's getting confused. Debugging against the interp stuff, I'm close to narrowing down exactly what's breaking. I was just hoping someone in the community had already done it. =) On a related note - if I could swap out the managed stack / execution point, and later swap that back in - that would be another way to go. This is just to get LUA-like coroutines - I'll never need to fiber native code... thx, bruce --- "Chad Z. Hower" <[EMAIL PROTECTED]> wrote: > :: It's unlikely to ever work. Please read the > "Dire warnings about > :: fibers" section at: > > A bit off topic - but I've done a lot of work with > Fibers. Delphi supports > fibers just fine using the Indy library. The VCL > (Kind of like STL / FCL for > Delphi) had 1-2 items, but appropriate hooks allows > Indy to handle them. > > I've looked at making it work in .NET and have had > some reasonable success, > but the biggest problem is debugging them. VS gets > really confused... Mind > you the Delphi debugger can be interesting to use > with fibers too, but it > does work and you can even tell what fiber you are > in with some > "extensions". > > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
