Message-Id: <200101081844.NAA08568@qnx.com> Subject: Re: valloc and memalign draftu To: djgpp-workers AT delorie DOT com Date: Mon, 8 Jan 2001 13:44:45 -0500 (EST) From: "Alain Magloire" In-Reply-To: from "Eli Zaretskii" at Jan 08, 2001 09:16:05 AM X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Ha ! ok, thanks for taking the time to clear the clouds. -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!