Mail Archives: djgpp/1997/03/18/08:38:52
In <Pine DOT SUN DOT 3 DOT 91 DOT 970312001408 DOT 2704Y-100000 AT is> Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:
>On 11 Mar 1997, Caspar Derksen wrote:
>> With DJGPP, alarm() or signal() does not seem to work, although the
>> FAQ suggests that signals and alarm should work.
>Do you say that only based on the test program that you posted, or did
>yoy try using `alarm' with a real program too? Your test program will
>indeed prevent `alarm' and `signal' from working, because it doesn't
>touch any memory while it loops in `main'. In DJGPP, signals are
>implemented in a way that the signal handling is deferred until the
>program is in its main execution thread and touches some of its data.
>Therefore, a tight loop which doesn't access any memory is one of the two
>cases which will defer the signal from being delivered until you exit
>that loop. The other case is when your program calls a real-mode service,
>like some DOS function, in which case the signal handler will be called
>when that DOS function returns.
alarm() indeed raises a signal that can be handled by a function installed
with signal(). This provides a portable way of creating timers.
The problem in my application was caused by DJGPP's alarm() always returning
0 instead of the number of seconds remaining until any previously scheduled
alarm was due to be delivered, as on most Unix systems.
The alarm() function can be fixed easily by getting the old timer value
from setitimer(). However, setitimer() then calls getitimer(), and this
function has not yet been implemented in DJGPP's libc. Fixing getitimer()
requires quite some knowlegde on DJGPP internals.
Caspar
- Raw text -