Path: utzoo!attcan!uunet!snorkelwacker!apple!vsi1!octopus!stever
From: stever@Octopus.COM (Steve Resnick )
Newsgroups: comp.os.msdos.programmer
Subject: Re: MSC, interrupts & functions
Message-ID: <1990Sep28.170019.2687@Octopus.COM>
Date: 28 Sep 90 17:00:19 GMT
References: <8539@helios.TAMU.EDU> <10850002@hp-ptp.HP.COM>
Reply-To: stever@octopus.UUCP (Steve Resnick )
Organization: Octopus Enterprises, Cupertino CA
Lines: 67

In article <10850002@hp-ptp.HP.COM> marcb@hp-ptp.HP.COM (Marc Brandis) writes:
>>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.
>

printf in this case is NOT re-entrant. printf() writes a string to stdout, 
which in turn makes a call to DOS to write the string. MS DOS is not 
re-entrant either. Another thing to note, if MSC uses the same stdio structures
as TC does, then *any* stdio call should be considered non-reentrant. (look
at stdio.h). 

I write a lot of concurrent code under DESQview on MS DOS. Under DESQview, the
environment allows for a single .EXE file to have several concurrent tasks. The
problem of re-entrancy has come up there a lot, too. MS DOS is taken into
account for, but the standard library, which gets shared between 2 or more
tasks, is not. The programmer has to take into account those considerations.
After a couple of years of working with TC and DESQview, I have found that a
large number of the standard library (especially stdio) is non-reentrant.
As Mr. Brandis pointed out, the re-entrancy can be determined largely by
how a function operates: If it uses static, or global variables it is not
re-entrant, if it doesn't it might be. The trick is to experiment a little, or
write your own re-entrant routines.

Cheers!
Steve

-- 
----------------------------------------------------------------------------
steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick
Flames, grammar errors, spelling errrors >/dev/nul
----------------------------------------------------------------------------