delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/01/12/04:20:19

Date: Mon, 12 Jan 1998 11:17:25 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: DJ Delorie <dj AT delorie DOT com>
cc: Shawn AT talula DOT demon DOT co DOT uk, robert DOT hoehne AT gmx DOT net, djgpp-workers AT delorie DOT com
Subject: Re: Request for comments: SIGQUIT in DJGPP v2.02
In-Reply-To: <199801111908.OAA25285@delorie.com>
Message-ID: <Pine.SUN.3.91.980112111655.1820A-100000@is>
MIME-Version: 1.0

On Sun, 11 Jan 1998, DJ Delorie wrote:

> The default handler for SIGQUIT should be SIG_IGN instead of unix's
> standard core dump. Even setting SIGQUIT to SIG_DFL should set it to
> SIG_IGN.  When SIGQUIT is ignored, that key should be treated as any
> other key.

OK, I will try to make this happen this weekend.

There's one thing that I don't understand, though, and it might affect
the implementation of this.  It seems that our hardware keyboard
handler in exceptn.S leaves the key to be read by the previous
handler(s) we are chaining to.  If this is true, what trick do we pull
for that?  I always thought that when you read the keyboard port, you
remove the keystroke and it cannot be read again.  Since our handler
does read that port, I am definitely missing something here.

I'm asking this because of the ``that key should be treated as any
other key'' part above.  If the keystroke is indeed left in the
keyboard controller, then we don't need anything special besides
setting the signal handler to SIG_IGN to achieve that.  Is this
correct?

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019