Date: Wed, 29 Aug 2001 14:35:02 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Rafal Maj <rmaj AT mail DOT pgd DOT pl>
cc: djgpp AT delorie DOT com
Subject: Re: Litle help ?
In-Reply-To: <001d01c13060$5a2bd420$d5000a0a@cerber>
Message-ID: <Pine.SUN.3.91.1010829142915.16952D-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Wed, 29 Aug 2001, Rafal Maj wrote:

> 2) Multitasking... currenty I'm using alarm() to prevent system hangs... but
> I don't now how to implement or sikmulate multitasking... if I can only now
> adress (processor state as in longjump) of instruction that was
> about to execute when sigalrm was rised...

The DJGPP signal-handling machinery already saves this information for 
you, you just need to know where to look ;-)

Specifically, #include <setjmp.h> and <sys/exceptn.h>, and then use 
the variable __djgpp_exception_state, which is an instance of jmp_buf.  
The signal-handling code saves in that variable the entire processor 
state when the alarm went off.  So you can later longjmp using 
__djgpp_exception_state, examine the EIP value, etc.  For examples of 
using this info, see the file dpmiexcp.c in the library sources 
(djlsr203.zip).

> why SIGALRM has only 1 sec resolution ?

One word: compatibility.

> Can I rise some signals in regular
> time spaces less then 1 sec ?

Yes; use setitimer instead of alarm.  It has the 54-millisecond 
resolution of the system clock.