Date: Mon, 8 Jan 2001 09:16:05 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Alain Magloire cc: djgpp-workers AT delorie DOT com Subject: Re: valloc and memalign draftu In-Reply-To: <200101080042.TAA17315@qnx.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 7 Jan 2001, Alain Magloire wrote: > > > By this do you mean, on many other OS implementations, the signal handler > > > is run on a separate stack. There are good reasons for doing it this way. > > > > Of course, there are good reasons to do that. Except that in DJGPP, > > these reasons don't exist. > > Well one of the obvious reason, is if you reach your stack limit and > been hit by a SIGVEC or something, running the handler on an alternate > stack will allow you to recuperate. DJGPP does that, too. (I didn't describe all the intricacies of the GPF exception handler.) The exception handler always starts on an alternate locked stack, but once it determines that the GPF was caused by the interrupt handler's resetting the data segment limit, it switches to the normal stack. So, to clarify: signal handlers for _real_ problems, such as SIGSEGV or SIGILL, run in semi-special context, and cannot return to the original code. But signal handlers for SIGINT, the timer, and other events which are translated into fake GPFs, run in normal application context.