Date: Mon, 20 Oct 1997 14:43:07 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Chris-top-her <cknight AT nmt DOT edu>
cc: djgpp AT delorie DOT com
Subject: Re: Help w/ Interrupts
In-Reply-To: <628ni2$dct$1@newshost.nmt.edu>
Message-ID: <Pine.SUN.3.91.971020144152.29791B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On 17 Oct 1997, Chris-top-her wrote:

> I'm attempting to implement coroutines using DJGPP, w/ csdpmi as my
> dpmi server.  I am able to do a manual call to my sched routine and
> everything is fine, but if I try to set it as the fn to call when a
> timer interrupt happens the program dies on me.

You should always post the exact messages, if any, that were printed
when the program crashes.  ``Dies on me'' has a lot of emotional
content, but doesn't help a bit to understand what might be wrong.

> The best I've been
> able to do is get 1 manual call, and 1 interrupt call to sched.  I've
> read through the faq on interrupts, and the problem I'm having seems
> no clearer.  Any help would be appreciated.  I include source below.

The source you posted lacks some details which might be crucial (for
example, the function `next_function' is nowhere to be found).
Assuming that no important details were left out, here's the things
that need to be corrected first:

	1. You didn't lock in memory your timer interrupt handler, the
	   functions that it calls, and any data it touches.
	2. It is possible that you leave the system with interrupts
	   disabled (`sched' calls `next_function' after disabling
	   them, and I cannot verify whether `next_function' enables
	   them back, and on what condition).

In general, this approach might have serious drawbacks, since you call
application-level functions (the coroutines) from within a hardware
interrupt handler.  This means that all the code and data of those
coroutines must be locked (i.e., you don't have virtual memory), and
various other bad consequences (e.g., the coroutines cannot call DOS
functions at all, because the timer interrupt itself might have
happened in the middle of a DOS call).

So I would advise to stay away from this approach, unless you have
grave reasons (like if you must meet hard time constraints), and are
prepared to live with the above limitations.

A simpler approach would be to install `sched' as a handler for the
signal SIGALRM and use `setitimer' function to get periodic alarms.
This might sometimes delay rescheduling (because signal delivery is
delayed when your program switches to real mode, e.g., to call a DOS
function), but it's much safer.

(Btw, I didn't inspect your code too much, especially its assembly
parts.)