Prev: Setting Service ACL in Win7 Not Working All the Time?
Next: IIS + ISAPI + EXE + Kernel Namespace + User Accounts + Security Model
From: Jochen Kalmbach [MVP] on 29 Apr 2010 04:06 Hi Leo! > AFAIK the fibers themselves can move between threads. The things you > may want to run *on* fibers may have thread affinity and cause > problems (e.g. apartment threaded COM objects) but you'd have those > problems with any mechanism which moved code calling those things > between threads. > > Can't say that I've ever used fibers, since they only make sense to a > very tiny niche which I've never found myself in, but that's my > understanding of them. I use fibers alot, and it works great! There are no problems with multiple-threads and fibers... -- Greetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/
From: Chris Becke on 29 Apr 2010 04:23 On 29/04/2010 06:23, olk wrote: > m schrieb: >> I am curious why you think that it is a good idea to build this? > > Ofcourse - I got my lib working on several UNIX systems. Only Windows > makes it difficult. > > It >> will be 1) hard; > > probably > > 2) fragile and is probably, like fibers, mostly useless. > > WIN32 Fibers are uselees because not migrateable between threads. They arn't? Ooops. Someone should tell Raymond: http://blogs.msdn.com/oldnewthing/archive/2010/02/25/9969014.aspx > The lib I try to create provides 'continuations'/'coroutines' for C++ > (similiar to features of GO, Python -> call/cc). and fibers are fantastic for this. I face the inverse task of trying to port my co-routines with fibers approach to linux & Mac OS.
From: Hector Santos on 29 Apr 2010 04:47 Jochen Kalmbach [MVP] wrote: > Hi Leo! > >> AFAIK the fibers themselves can move between threads. The things you >> may want to run *on* fibers may have thread affinity and cause >> problems (e.g. apartment threaded COM objects) but you'd have those >> problems with any mechanism which moved code calling those things >> between threads. >> >> Can't say that I've ever used fibers, since they only make sense to a >> very tiny niche which I've never found myself in, but that's my >> understanding of them. > > I use fibers alot, and it works great! There are no problems with > multiple-threads and fibers... Can you cite some practical usage examples? How it helps? thanks. -- HLS
From: Jochen Kalmbach [MVP] on 29 Apr 2010 05:02 Hi Hector! >> I use fibers alot, and it works great! There are no problems with >> multiple-threads and fibers... > > Can you cite some practical usage examples? How it helps? thanks. What do you mean? SwitchToFiber / CreateFiber / ConvertThreadToFiber? These function are not tooo complicated. If you need some advantage out of these functions, you need to "build" alot infrastructure around these functions.... I have here a completely multi-tasking-system (cooperative) which also supports "free threading tasks". You can join/leave tasks from the cooperative system... It is very helpfull if you have many tasks, but you will not care about multi-threading. I use it for a "real-time" program on XP. Or what exactly do you want to see? -- Greetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/
From: Hector Santos on 29 Apr 2010 05:58
Jochen Kalmbach [MVP] wrote: > Hi Hector! > >>> I use fibers alot, and it works great! There are no problems with >>> multiple-threads and fibers... >> >> Can you cite some practical usage examples? How it helps? thanks. > > What do you mean? SwitchToFiber / CreateFiber / ConvertThreadToFiber? > These function are not tooo complicated. But how are they applied, when are they useful? What purpose do they serve? When can they apply or don't? Reading wikipedia http://en.wikipedia.org/wiki/Fiber_(computer_science) gave a basic understanding to see/how they are may be applicable. > If you need some advantage out of these functions, you need to "build" > alot infrastructure around these functions.... > I have here a completely multi-tasking-system (cooperative) which also > supports "free threading tasks". You can join/leave tasks from the > cooperative system... > > It is very helpfull if you have many tasks, but you will not care about > multi-threading. I use it for a "real-time" program on XP. Ok, that is a good practical example where it may be applied. > Or what exactly do you want to see? Case scenarios, like "real time" example where you need, I guess more predictability with "Fiber Residence Time." I never used them, but reading about them (briefly) in the past, I always thought where it might be useful is to split thread work within a thread. I had the idea it was something like: Fiber1 Process -> Thread --> Fiber2 ... FiberX Where a thread needed to do X jobs quickly with minimum stack overhead before it can continue. But as MSDN stated: "In general, fibers do not provide advantages over a well-designed multithreaded application." I didn't think I would need it. I'm also doing a lot more with IOCP and I/O based thread scheduling, so your comment spiked my interest if FIBERS are useful for the work I am doing (or not). If I understand it more, it sounds fibers can degrade the improvements gained with IOCP optimized thread scheduling? -- HLS |