Mail Archives: djgpp/1997/12/10/20:12:15
> 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++;
}
- Raw text -