Mail Archives: djgpp-workers/2001/01/22/15:31:30
> From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> Date: Mon, 22 Jan 2001 19:04:14 +0100
>
> > Is it possible that SIGALRM happens more than once? If so, the second
> > time will abort the program, because the above handler resets the
> > SIGALRM handler to SIG_DFL.
> Yes, but the function that sets the alarm in the first place, first sets
> the signal handler to the function it's passed (i.e. timeoutHandler).
I thought about a possibility that a single setitimer call causes more
than one SIGALRM. It shouldn't happen, since the timer is set for
one-shot operation, IIRC.
> > What do disableInterrupts() and enableInterrupts() do? What
> > ``interrupts'' do they disable/enable?
>
> IntState
> disableInterrupts()
> {
> sigset_t newSet;
> static sigset_t oldSet;
>
> if (disabled) {
> /* let only the outermost calls actually block and unblock signals */
> return ((IntState) NULL);
> }
> disabled = true;
> sigfillset(&newSet);
> sigprocmask(SIG_BLOCK, &newSet, &oldSet);
> return ((IntState) &oldSet);
> }
This blocks signals. When they are unblocked by enableInterrupts, any
pending signals are immediately delivered. If SIGALRM is pending at
that point, it will abort the program.
However, the traceback you posted shows that the signal happens when
the program is inside __dpmi_yield, not in enableInterrupts...
> What I expect happens is that the __dpmi_yield() takes so 'long' that
> a second alarm gets set
If the program is in __dpmi_yield, how can it set a second alarm?
> (if two alarms are set, do they BOTH fire?)
No. There's only one timer, so setting it again nukes the first one.
Anyway, you could modify __dpmi_yield to print on the screen whether
SIGALRM is hooked or not, and then run the program and see what
happens. (Be careful not to use printf or anything fancy, though. I
suggest simply write 0 or 1 to some point on the screen with
farpokeb.)
- Raw text -