Date: Wed, 26 Jan 2000 14:38:23 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Alain Magloire <alain AT qnx DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: posix threads with djgpp
In-Reply-To: <86loe8$kbv$1@gateway.qnx.com>
Message-ID: <Pine.SUN.3.91.1000126143401.6180M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On 26 Jan 2000, Alain Magloire wrote:

> reentrancy: system calls, the same buffer is use for all systems. So
> if one thread does, let say a read() and the otherone a readdir()
> they may intertwine, or something like that I was told.

This latter aspect is not a problem in the DJGPP case, because signals in 
general, and timers in particular, are deferred until the system call 
returns.  This is because the DJGPP signal machinery is based on 
triggering an exception in such a way that it only happens when the 
program is in protected mode and touches some of its data.

The price for this is that if a program is parked inside a DOS call, like 
if it reads from the keyboard, the signals (and threading that is based 
on SIGALRM) are not delivered until the DOS call returns.  So, for 
example, if you spawn a subsidiary program, threading stops until the 
child program returns.