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" <alain AT qnx DOT com>
In-Reply-To:	<Pine.SUN.3.91.1010108091115.4690I-100000@is> from "Eli Zaretskii" at Jan 08, 2001 09:16:05 AM
X-Mailer:	ELM [version 2.5 PL0b1]
MIME-Version:	1.0
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

> 
> 
> 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 !!!

- Raw text -