Date: Sun, 21 Jan 2001 15:09:34 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Van Holder cc: djgpp-workers AT delorie DOT com Subject: Re: Interaction between __dpmi_yield and signals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 21 Jan 2001, Tim Van Holder wrote: > the Smalltalk testsuite has a test for its delay mechanism, which > aborted due to a SIGALRM, even though a signal handler was properly > installed. I tracked the problem to a function called 'relinquish', > which uses select() to relinquish control for a short time. Using > sleep() gave the same result, probably because both called > __dpmi_yield(). Changing the relinquish() function to do nothing at > all on DJGPP does work, however. I just don't see why calling > __dpmi_yield would cause a SIGALRM not to be delivered properly. It shouldn't. Moreover, I think I've seen a signal interrupt `__dpmi_yield' many times, with no visible problems. First, make sure the problem persists with stock v2.03 library. If it does, I'd first suspect that Smalltalk's `relinquish' isn't as innocent as your description suggests; perhaps it does something which in the DJGPP case disables or interferes with the signal handling machinery. As another data point, does a simple test program which sets up a timer and then calls `select' to wait forever succeeds to DTRT? Also, make sure you do NOT run this under a debugger. The DJGPP debug support doesn't work reliably when timers fire, this is a known bug for which there's no solution or work-around yet. If you did run this under a debugger, chances are your observations have very little to do with the actual problems.