Date: Sun, 27 Feb 2000 10:26:34 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: OiSyN cc: djgpp AT delorie DOT com Subject: Re: alarm signal for multithreading In-Reply-To: <951589170.6346.0.pluto.d4ee0fa5@news.demon.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.