From: caspard AT sci DOT kun DOT nl (Caspar Derksen) Newsgroups: comp.os.msdos.djgpp Subject: Re: signal() and alarm() - Bug? Date: 14 Mar 1997 17:35:49 +0100 Organization: University of Nijmegen, The Netherlands Message-ID: <5gbup5$2i8@hera.cs.kun.nl> References: NNTP-Posting-Host: hera.cs.kun.nl Lines: 32 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp In Eli Zaretskii 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