Mail Archives: djgpp/2000/02/27/04:48:26
On Sat, 26 Feb 2000, OiSyN wrote:
> I set my a signal handler with signal (int, void(*)()). That handler
> contains some taskswitching code, so the handler never returns, but
> jumps to another code section. But if the handler doesn't return,
> another signal can't be caught. I think because djgpp thinks that
> the signal isn't completely handled, since it doesn't return...
No, this isn't true: there's no requirement that the signal handler
returns, it might as well longjmp anywhere. The DJGPP debug support
and the floating-point emulation both longjmp on a signal, and they
both work. If it doesn't work for you, I'd say you have a bug ;-).
> Does someone know how to point out to DJGPP that the signal IS handled,
> so I can catch another SIGALRM (or another signal) later on?
As far as the DJGPP signal-handling machinery is concerned, the signal
is considered ``handled'' the moment your handler is called. The
signal handler is called in the normal DJGPP context, as any other
function call, so it (the handler) can do whatever a normal C function
is allowed to do, including longjmp.
Are you sure you schedule another SIGALRM in the signal handler?
Perhaps the way you call setitimer is incorrect, and the timer never
fires again?
> By the way, what's the calling convention for a signal? Is it like
> an interrupt routine?
No, it's a normal C function.
> I hope it is, 'cause I need the flags which are pushed by an
> interrupt call.
Why would you care about the flags?
Anyway, you can't get at them: by the time your handler is called,
they are long gone. The handler isn't called from the interrupt
handler, so the flags are not really relevant.
> Or does someone know what exception is raised when an alarm signal
> is raised?
The exception is GPF, the general protection fault.
But it's the other way around: the timer tick interrupt handler (which
is installed by the library when you call setitimer) arranges for the
GPF to happen the first time the program touches any of its data. The
GPF exception handler then calls your signal handler, after cleaning
up the mess which caused the GPF.
> Then I can hook the
> exception handler and have the flags I need on the stack, and I
> don't have to bother about my first problem (signals disabled).
This is the wrong way to solve your problem. You need to debug your
code to find the reason why the signal doesn't happen more than once.
When you find the reason and correct it, your code will simply work,
no need to worry about any flags.
- Raw text -