Path: utzoo!attcan!uunet!mailrus!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!hplabs!hpcc05!hp-ptp!marcb
From: marcb@hp-ptp.HP.COM (Marc Brandis)
Newsgroups: comp.os.msdos.programmer
Subject: Re: MSC, interrupts & functions
Message-ID: <10850002@hp-ptp.HP.COM>
Date: 26 Sep 90 21:39:27 GMT
References: <8539@helios.TAMU.EDU>
Organization: HP Pacific Technology Park - Sunnyvale, Ca.
Lines: 65

>I have successfully written a program that uses interrupt 1Ch to beep
>the speaker every few seconds.  However, after trying to spruce it up
>I have noticed that functions called by an interrupt (declared void
>interrupt far) cannot call other functions declared simply void or int.
>After reviewing the Microsoft manual I could find no clarification or
>discussion of what limitations are placed on a function called by an
>interrupt.  Can anyone enlighten me?? Possibly I'm not suppose to
>call the C library also???
>
>Below is a simplified code segment example.  In addition, the documents
>on how to restore a vector after your finished with it are skimpy, I
>assume I'm doing the right thing.
>
>void beep()
>{
>   printf("beep\n");
>}
>
>void interrupt far count()
>{
>   if (cbeep_count > beep_count)
>   {
>      beep();                           /* beep ..crashes here */
>      cbeep_count = 0;                  /* reset counter */
>   }
>   else
>      ++cbeep_count;
>}
>
>-Chet Laughlin

I do not see any reason, why you should not be able to call any 
procedure that is reentrant. Reentrancy means (in this context),
that you can interrupt some procedure p and then call the same procedure
p from the interrupt handler. As a rule of thumb, procedures that do
not use static variables (or globals, anything that is not lying on
the stack) are reentrant. I think several parts of the MSC library
are not (!) reentrant.

Moreover, you should make sure that your interrupt handler takes only
a small amount of time to execute, so printf is certainly something
that you should avoid (and beep as well). Consider that you get an
interrupt every x milliseconds. If your interrupt handler takes more
than x milliseconds to execute, then the 2nd interrupt interrupts 
your handler while it is handling the first interrupt. This stacking
up of interrupts continues until the system dies with a stack over-
flow.

If you cannot avoid to have an interrupt handler that may take more
than this x milliseconds to execute, you should build in some code
that detects when the handler is interrupted itself and do something
reasonable with it. Make sure that these actions are atomic. For
more information on how to do it, see literature about concurrent
programming.


(* I speak only for myself.
	Marc-Michael Brandis
	Institut fuer Computersysteme
	ETH Zentrum
	CH-8092 Zuerich, Switzerland
	e-mail: brandis@inf.ethz.ch
		brandis@iis.ethz.ch
   Temporarily at HP, marcb@hp-ptp.ptp.hp.com
*)