From: Luke D. <cod...@ho...> - 2003-03-14 01:15:34
|
>From: Andy Ross <an...@pl...> >To: min...@li... >Subject: Re: [Mingw-users] Longjmp in signal handler >Date: Thu, 13 Mar 2003 09:09:54 -0800 > >Roger K. Wells wrote: > > What's the problem as long as setjmp() stores ESP in the jmp_buf and > > longjmp() sets the same ESP? This works fine on djgpp (DOS) and btw. > >Because the signal handler doesn't share the same stack pointer as the >process does. On some platforms, you can longjmp back into main() >from the signal handler because the OS sets up the handler context >immediately below the process stack (it looks like a function call to >longjmp). But if you change the stack, and return from the handler, >the regular process sees its local variables change out from under it. >Doing the longjmp changes only the handler's notion of where the stack >is, not the process's. Setting the ESP register to a new value can't >change the *original* ESP value that the OS stashed away in memory you >can't touch. > >If your handler does nothing but exit, then the process never runs >again and you are fooled into thinking it "worked". If you never >return to main(), then you never see the corrupt stack area and you >are fooled into thinking it worked. But if the handler makes other >function calls and changes the stack, and then returns, you're toast. > >Don't do this. It doesn't work the way you think it does. Again, >think of the handler as a separate thread. You aren't allowed to have >thread A take a vacation and run for a while on thread B's stack, are >you? > >Andy > >-- >Andrew J. Ross Beyond the Ordinary Plausibility Productions >Sole Proprietor Beneath the Infinite Hillsboro, OR > Experience... the Plausible? Exactly, and in fact the MSDN documentation for signal() says that SIGINT actually *is* handled in a separate thread: "Note SIGINT is not supported for any Win32 application, including Windows 98/Me and Windows NT/2000/XP. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior." And for all signal handlers it also says: "Do not use longjmp unless the interrupt is caused by a floating-point exception". The use of printf() is illegal too. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_signal.asp Luke _________________________________________________________________ Hotmail now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp |
From: Michel G. <mg...@co...> - 2003-03-14 09:30:47
|
Many thanks to all who responded. To sum up the answers: "Don't do that because the OS makers don't allow it." IMHO this is an artificial OS and/or RT library limitation which _should_ :) not exist, as the semantics of longjmp() allows for it, maybe with an added field in the jmp_buf for storing the thread id. Anyway, back to the drawing board. To achieve the same result, I think of starting a new thread to do the work, have the main thread create an event, then block in WaitForSingleObject(). On receiving Ctrl-C, the SIGINT handler would SetEvent() then return, waking-up the main thread which can terminate - gracefully :)) - the worker thread. I suspect that, even if not explicitely documented, SetEvent() could work in a SIGINT handler. Michel |