cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1999/03/17/07:06:26

Date: Wed, 17 Mar 1999 11:38:54 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Jonathan Villani <jonathan DOT villani AT videotron DOT ca>
cc: djgpp AT delorie DOT com
Subject: Re: "Locking" code
In-Reply-To: <AfBH2.3062$AI1.2335@weber.videotron.net>
Message-ID: <Pine.SUN.3.91.990317113837.11125W-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, 16 Mar 1999, Jonathan Villani wrote:

> static void SB_interrupt_handler()
> {
> 
> code
> ...
> read_chunk();       /* <------------- In this  function I call fread*/
> ...
> }
> 
> 
> My question: if I lock the read_chunk function, is this code safe?
> Does it locks automatically the "fread" in the read_chunk function?

You should *never* call DOS inside a hardware interrupt handler.  If
the interrupt happens in the middle of another DOS call, your code
will reenter DOS and wedge the machine, since DOS is not reentrant.

In addition, library functions are not locked, unless you set the
`_CRT0_FLAG_LOCK_MEMORY' bit in `_crt0_startup_flags'.  So calling
library functions is also a bad idea.

Btw, if you run that code under CWSDPMI, it will crash your program,
as section 18.11 of the FAQ explains.

The best way to avoid such problems is to have the interrupt handler
set a flag, so that the foreground part of your program could check
that flag and read the data from file.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019