Date: Thu, 23 Jan 1997 08:58:13 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Kristian Hogsberg Kristensen <hogsberg AT cruzeiro DOT daimi DOT aau DOT dk>
cc: djgpp AT delorie DOT com
Subject: Re: exception processing overhead
In-Reply-To: <y6ysp3tu95q.fsf@cruzeiro.daimi.aau.dk>
Message-ID: <Pine.SUN.3.91.970123085127.3044I-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On 22 Jan 1997, Kristian Hogsberg Kristensen wrote:

> if locking all accessed memory is non-trivial). But I 
> fear that there is a considerable overhead when
> handling hw-interrupts this way. The processing on 
> the client side I can figure out from the exception 
> processing code, what I'm asking is: What is
> the extra overhead in the DPMI-host (say, CWSDPMI) 
> when using this technique? Could this be used for high
> frequency timer interrupts?

AFAIK, the overhead inside the DPMI host isn't the issue here.  The main
problem is that your signal handler is only called when your program is
back in its mainline code, in protected mode, and touches some of its
data.  If some of these conditions are not met, then you don't see the
interrupt.  For example, if the hardware interrupt hits when you are
inside a long DOS or BIOS call (e.g., when you read keyboard input), or if
your program is in a tight loop which never accesses memory, only
registers, the signal handling is delayed until such time as these
chores are done. 

Therefore, I don't think this technique is appropriate to handle hardware 
interrupts, unless no harm is done when you lose some of them occasionally.