Date:	Mon, 8 Jan 2001 09:16:05 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Alain Magloire <alain AT qnx DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: valloc and memalign draftu
In-Reply-To:	<200101080042.TAA17315@qnx.com>
Message-ID:	<Pine.SUN.3.91.1010108091115.4690I-100000@is>
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.

- Raw text -