SEH not working with new stack (stack swapping)
in [Win32 Kernel]
|
Prev: Setting Service ACL in Win7 Not Working All the Time?
Next: IIS + ISAPI + EXE + Kernel Namespace + User Accounts + Security Model
From: Pavel A. on 29 Apr 2010 06:04 "olk" <oliver.kowalke(a)gmx.de> wrote in message news:hrb1f4$1k6$03$2(a)news.t-online.com... > Pavel A. schrieb: >> Yes, SEH places special markers in the stack. >> You've asked for a trouble and got it. >> -- pa > > What are those markers? Chain of pointers to previous exception frames. Disassemble a __try __ except block, and you'll see this. -- pa
From: Jochen Kalmbach [MVP] on 29 Apr 2010 06:33 Hi Hector! > 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 This is a bad example... if you want to get the work "quickly" you should use threads. > Where a thread needed to do X jobs quickly with minimum stack overhead > before it can continue. This is exactly the reasons for *threads* and not fibers! > "In general, fibers do not provide advantages over a well-designed > multithreaded application." Yes. This is true. But there are some (rare) cases, whe you do not want the "overhead" of synchronisation. And then fibers are very usefull. But you mast take care, what functions you call inside these fibers, so that other fibers also will be able to run... In my case, I have a complete multi-tasking-system with all the needed functions like "Sleep, MessageQueues, ...). The app-developer is not allowed to call any Win32-OS functions!!! Only in this "own world", you can have a "good" fiber-design. Or in very rare situations... > 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? The most important advantage is: The scheduling is done in user-mode and therefor to kernel-transition is needed! SO you can switch very fast from one fiber to an other. -- Greetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/
From: rogero on 29 Apr 2010 06:43 On Apr 28, 2:17 pm, rogero <roger....(a)gmail.com> wrote: > - The OS may be validating that the elements on the exception chain > are between StackBase and StackLimit. This does appear to be the case. Can you change these values to match your replaced stack? I suspect this moves into somewhat undefined territory ... Roger.
From: Chris Becke on 29 Apr 2010 10:10 On 29/04/2010 10:47, Hector Santos wrote: > 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. I use fibers in a single threaded scenario. I have a game engine with animation commands. Something like this: sprite::move_to(int x, int y, int time,int event); Notice the last parameter - "event". Later in the code I call a function: fibermgr::waitfor(int cEvents, int event1,...); Then, I create a number of fibers that act as entry points for animation manager code. In those fibers I can write simple syncrhonization code. To move two sprites, play a sound, AND wait for a sever response, animation code can look this simple: void a_fiber_proc() { ... sprite1.move_to(x,y,t,101); sprite2.move_to(x2,y2,t2,102); soundfx::playfx(sound,103); comms::sendpkt(&pktdata,104); ... fibermgr::waitfor(4, 101, 102, 103, 104); ... } The fibermgr::waitfor function keeps a table of fibers, and event codes and keeps choosing the next fiber that isn't waiting for anything. When all the fibers are waiting for an animation to complete, it schedules the "main" fiber of the application that runs the message pump. Each time the message pump runs out of windows messages, it calls the fiber dispatcher to activate any fibers that might need to be released, based on animations completing or packets arriving. All this without the overhead implicit in discreet threads.
From: Hector Santos on 29 Apr 2010 13:31
So, overall, the benefit is in "smooth animation?" due to less thread transition overhead? Sounds to me that the top level benefit is providing a "predictable" order of work. One thing I don't quite understand is the description commonly used that somewhat implies fibers are "non-preemptive" but cooperative multitasking when compared to threads. Of course, they are preemptive otherwise everything will grind down to a halt. It suggest that the thread fibers themselves are split units of multitasking work. These units of work must complete or switch to another task (fiber). This predictable work flow. Is that a fair basic description? I guess I have to play with them, but so far I am not believing the descriptions I am getting. Seems to be incorrect. :) Like one fellow in some link stated, a common copied statement: "Threads use pre-emptive scheduling, whereas fibers use cooperative scheduling." That doesn't make sense to me. All things are pre-emptied. But since only one thread fiber with a set can run at a same time, it behaves as a multi-tasking model. Thanks -- HLS Chris Becke wrote: > I use fibers in a single threaded scenario. > I have a game engine with animation commands. Something like this: > > sprite::move_to(int x, int y, int time,int event); > > Notice the last parameter - "event". Later in the code I call a function: > > fibermgr::waitfor(int cEvents, int event1,...); > > Then, I create a number of fibers that act as entry points for animation > manager code. In those fibers I can write simple syncrhonization code. > To move two sprites, play a sound, AND wait for a sever response, > animation code can look this simple: > > void a_fiber_proc() > { > ... > sprite1.move_to(x,y,t,101); > sprite2.move_to(x2,y2,t2,102); > soundfx::playfx(sound,103); > comms::sendpkt(&pktdata,104); > ... > fibermgr::waitfor(4, 101, 102, 103, 104); > ... > } > > The fibermgr::waitfor function keeps a table of fibers, and event codes > and keeps choosing the next fiber that isn't waiting for anything. When > all the fibers are waiting for an animation to complete, it schedules > the "main" fiber of the application that runs the message pump. > Each time the message pump runs out of windows messages, it calls the > fiber dispatcher to activate any fibers that might need to be released, > based on animations completing or packets arriving. > > All this without the overhead implicit in discreet threads. > -- HLS |