Date: Wed, 9 Feb 2000 09:02:48 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: ayoung cc: djgpp AT delorie DOT com Subject: Re: Threads In-Reply-To: <38A123D5.14EEA3A6@pacific.net.hk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 8 Feb 2000, ayoung wrote: > Thanks for this little insight as I over looking the importance of > the int(0x31) call within __djgpp_hw_exception. You mean the call to reset the DS limit? > The result of all this being that no existing DJGPP thread library could be > called real time Correct. > in fact there is the possibility of losing alarms > etc if there are high delays within DPMI and/or DOS services. Correct again. > Another option is to directly install > protect and real mode interrupt traps (i.e. not via DMPI) removing the > DMPI interrupt redirection **. This is extremely dangerous, unless you are willing to toss DPMI completely and do everything on your own. DPMI explicitly forbids switching stacks from a hardware interrupt handler. > Q: How does the debugger interface with the application, and iIs there a > document reference available ? I ask as any rework of the interrupt > construction will, most likely, effect this interface. The DJGPP debugger support is only scarcely documented. What docs there is, you can see it in libc.info: from the command line type "info libc functional debugging" and read there. Anything beyond that, you will have to ask here. In a nutshell, the debug support works by hooking the debug exception, and longjmp'ing between the debuggee and the debugger's own code. It is very similar to how the FP emulation works in DJGPP.