Date:	Sun, 18 Jan 1998 11:36:45 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Markus F.X.J. Oberhumer" <k3040e4 AT wildsau DOT idv-edu DOT uni-linz DOT ac DOT at>
cc:	DJ Delorie <dj AT delorie DOT com>, djgpp-workers AT delorie DOT com
Subject:	Re: Request for comments: SIGQUIT in DJGPP v2.02
In-Reply-To:	<199801160702.IAA22842@wildsau.idv.uni-linz.ac.at>
Message-ID:	<Pine.SUN.3.91.980118113605.18602A-100000@is>
MIME-Version:	1.0

On Fri, 16 Jan 1998, Markus F.X.J. Oberhumer wrote:

> I'm also more than a bit sceptic about the SIGQUIT extension.
> Many programs (like Allegro) currently install SIGQUIT handlers
> just to clean up at a possible crash.

I don't understand this comment.  If a program installs a handler for
SIGQUIT, it should not have any surprises with this change, since
pressing the QUIT key will just call that handler.  So what does
bother you, exactly?

> I strongly vote for an explicit `__djgpp_enable_sigquit()'.

I already said here that this is how it will be done.  By default,
SIGQUIT will be ignored (i.e., its SIG_DFL handler will discard the
signal and return).  Only programs which catch SIGQUIT by installing
their own handlers will get the signal.  A handler will be provided
that can be installed to generate a traceback and abort, as things are
set up on Unix, but a program will need to actually install that
handler by calling `signal' to have SIGQUIT abort it, like this:

	signal (SIGQUIT, __djgpp_traceback_exit);

> [ Is SIGQUIT really that important ?

It is important when you need it.

>   though running Linux for more than 3 years I even don't know where
>   this key is located on my German keyboard ]

With the above setup, you can continue to not know about it in DJGPP
as well.

- Raw text -