Mail Archives: djgpp-workers/2001/01/21/13:07:42
> Then you might consider replacing itimer.c with what's currently in
> the CVS: there was a small bug in the released version. I don't know
> if it affects this specific problem, but you never know...
Will try that.
> Please show the code which sets up the timer and the signal handler.
Seems to be this:
void
signalAfter(deltaMilli, func)
int deltaMilli;
RETSIGTYPE (*func)();
{
/* Please feel free to make this more accurate for your operating system
* and send me the changes.
*/
setSignalHandler(SIGALRM, func);
if (deltaMilli <= 0) {
kill(getpid(), SIGALRM);
} else {
#ifdef WIN32
#define ALARM_DONE
WaitForSingleObject(alarms.hCritEvent, INFINITE);
alarms.sleepTime = deltaMilli;
SetEvent(alarms.hCritEvent);
SetEvent(alarms.hNewWaitEvent);
#endif
#if defined(ITIMER_REAL) && !defined(ALARM_DONE)
#define ALARM_DONE
struct itimerval value;
value.it_interval.tv_sec = value.it_interval.tv_usec = 0;
value.it_value.tv_sec = deltaMilli/1000;
value.it_value.tv_usec = (deltaMilli%1000) * 1000;
setitimer(ITIMER_REAL, &value, (struct itimerval *)0);
#endif
#if defined(HAVE_FORK) && !defined(ALARM_DONE)
#define ALARM_DONE
static pid_t pid = -1;
long end, ticks;
if (pid != -1) {
kill(pid, SIGTERM);
}
setSignalHandler(SIGCHLD, SIG_IGN);
switch(pid = fork()) {
case -1:
/* Error, try to recover */
kill(getpid(), SIGALRM);
break;
case 0:
/* Child process */
end = getMilliTime() + deltaMilli;
do {
ticks = end - getMilliTime();
if (ticks > 1100) { /* +100 is arbitrary */
sleep((int) (ticks / 1000))
}
} while (ticks > 0);
kill (getppid(), SIGALRM)
_exit(0);
}
#endif
#if defined(HAVE_ALARM) && !defined(ALARM_DONE)
#define ALARM_DONE
alarm(deltaMilli / 1000);
#endif
#if defined(ALARM_DONE)
#undef ALARM_DONE
#else
/* Cannot do anything better than this */
kill(getpid(), SIGALRM);
#endif
}
}
For DJGPP, the setitimer system is used (though using
alarm() led to the same problem).
setSignalHandler either uses signal() or the posix signal functions
(sigemptyset/sigaction); again, tried both with the same results.
> And what is the value of the argument to `relinquish' in this
> particular test?
>
> This sounds like some problem with how the signal handler was set, or
> what it did. The above would be the expected result if the signal
> handler for SIGALRM was reset to SIG_DFLT. Can you add some debugging
> print-out to the signal handler that will show whether it is called or
> not?
I'll check.
> Oh, btw: this run on Windows, right? On Windows, you need to make
Yes.
> sure the DOS box where the program is running never goes int
> background, because Windows almost stops delivering timer tick
> interrupts to background programs (they get something like 10% of
> ticks).
No, was foreground all the time.
I did check the libc manual, Eli ;-P
> OK. But since we're dealing with an interpreted language, I figured trying
> to debug something would prove difficult even without the timer stuff.
> Why? I routinely run Emacs (another interpreter) under GDB with no
> visible problems. I even debug GDB itself with GDB, although it has a
> command-line interpreter built into it.
My bad - since it's byte-compiled, there's no problem stepping through the
routines that ibnterpret those bytecodes; somehow I thought I'd be stepping
through machine code that had been generated at run-time (which wouldn't
have debug info).
I'll build a stabbed version later and see what the debugger says.
- Raw text -