Date: Sun, 10 Oct 1999 12:16:28 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker cc: djgpp AT delorie DOT com Subject: Re: Problems using signals In-Reply-To: <7tifrr$3kn@acp3bf.knirsch.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 7 Oct 1999, Hans-Bernhard Broeker wrote: > > I could not interrupt the program using Ctrl-C. > > > Is this to be expected? > > Yes. Unlike in a 'real' operating system, keyboard-generated signals > in MS-DOS don't generally get delivered until the point were a program > reads the keyboard, or does any other kind of I/O. The underlying > problem is that your program is in protected mode (almost) all the > time, i.e. it doesn't call or use DOS at all. If DOS isn't doing any > work, it cannot detect the Ctrl-C keypress deliver an interrupt to > your program. This true for DOS itself, but not for DJGPP. The DJGPP startup code installs a hardware keyboard interrupt handler which watches specifically for Ctrl-C keystroke (and, beginning with v2.02, for Ctrl-\ as well), and generates SIGINT (SIGQUIT for Ctrl-\) almost immediately, even if the program doesn't read the keyboard. The way it works is as follows. The keyboard interrupt handler invalidates the DS selector by resetting its limit to the first page (a.k.a. null page) only, saves the original limit in a special variable, sets a flag which indicates that Ctrl-C was seen, and then does an IRET. Since all data is above the null page, we are guaranteed that the first time the program touches any of its data, it will trigger a GPF. The GPF exception handler, also set up by the startup code, sees that the exception is really a fake one generated by Ctrl-C, so it restores the DS limit to its original value and then does a "raise(SIGINT);". The ``almost immediately'' part is due to the fact that the signal is only raised when some of the protected-mode data is touched. If a program is parked inside a real-mode service or in a tight register-based loop, the signal delivery is deferred until the service returns or the loop ends. So, actually, if the program reads the keyboard (which involves a call to real-mode DOS or BIOS service), it will get the signal SLOWER than if it stays in protected mode at all times.