Message-Id: <9712110111.AA14333@gcef.gc.maricopa.edu>
Date: Wed, 10 Dec 1997 18:11:00 -0700 (MST)
From: "Joshua James Turpen" <44699 AT ef DOT gc DOT maricopa DOT edu>
To: eliz AT is DOT elta DOT co DOT il
To: djgpp AT delorie DOT com
Subject: Re:  Win95 and ___djgpp_hw_exception...
Precedence: bulk

> So why don't you save _old into the code segment?  Define it in assembly 
> in the code segment, and save the value there with inline assembly.  
> Shouldn't be too complex.
> 
> > So instead I just push the old sel:offset onto the stack and do an 
> > lret.  
> 
> Pushing onto the stack assumes too many things about the stack state, 
> which might be not true when you are inside a hardware interrupt handler.

I've re-written the test program yet again to use the ljmp method instead of
the lret method.  It still crashes after about a minute.

> 
> > Well, the code I've posted is just an example.  setitimer only has the
> > 18.2 hz resolution, and reprogramming the PIT is a no-no under windows. 
> > So instead of using the PIT I'm using the real-time clock interrupt (IRQ8)
> > which is somewhat programmable, and windows doesn't care if you re-program
> > it.    
> 
> If you are going to use the fake signal method to handle the interrupt, 
> IMHO going to a faster timer isn't worth the hassle, due to the way 
> signals are handled in DJGPP.  Your SIGILL handler will actually be 
> called only when the program is in protected mode and touches its data.  
> So, for example, if your program is parked inside a DOS call (e.g., waits 
> for a character to be typed by the user), or is inside a tight loop that 
> only uses registers and doesn't touch memory, the signal delivery is 
> deferred until the DOS call returns or the loop ends.
> 
> Therefore, using signals has its inherent unpredictable latencies, and it 
> doesn't make much sense to try to generate signals at a higher rate.

Yes, I understand that.  Actually, LWP relies on that fact because DOS is
not re-entrant.  If the signals were raised in the middle of a DOS call,
LWP would not work at all.  Under most curcumstances though, the program
is running in protected mode, not a dos call, so the speed up does help.


> 
> (The reason for this handling of signals is that you cannot safely do 
> many things when the signal interrupts a real-mode DOS/BIOS call, due to 
> DPMI complications.  See the library reference, under `signal' function, 
> for more details.)

I need the signal mechanism because I need the machine state.  Normally
it's available in an interrupt.  But under DPMI, the saved CS:EIP on the
stack points to the DPMI server, not the interrupted code.

Finally, here is my last test program that crashes.  I do not hook any
interrupts!  I use setitimer as you suggested.  

----------------begin test4.c--------------------
#include <sys/time.h>
#include <signal.h>
#include <stdio.h>

int tick;
void sig_handler(int signum);
main()
{
	struct itimerval t;
	t.it_interval.tv_sec = 0;
	t.it_interval.tv_usec =100;
	t.it_value.tv_sec = 0;
	t.it_value.tv_usec = 100; 
	signal(SIGALRM, sig_handler);
	setitimer(ITIMER_REAL, &t, NULL);
	while(!kbhit())
		{
		printf("Tick %d\n", tick);
		}

}	
void sig_handler(int signum)
{
	tick++;
}