Date:	Sun, 13 Feb 2000 09:48:37 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	ayoung <ayoung AT pacific DOT net DOT hk>
cc:	djgpp AT delorie DOT com
Subject:	Re: Threads
In-Reply-To:	<38A512E0.74EDF219@pacific.net.hk>
Message-ID:	<Pine.SUN.3.91.1000213094702.29873J@is>
MIME-Version:	1.0
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

On Fri, 11 Feb 2000, ayoung wrote:

> Agreed, the further one looks the larger the issue gets.  The
> solution is a for a PC-supervisor which should serialise DOS access
> of which there would be several methods of implementation from s/w
> int chaining to replacing the system calls.  For true real-time the
> supervisor would also need to shield the debugger from reentrant DOS
> calls (ie during break points any current DOS calls would need
> complete prior to passing contol to the debugger).

DOS reentrancy should not be an issue at all.  As long as you are
playing by the DPMI rules, you must make sure that no context switch
takes place while the program is in a DOS call.  If that's how
threading works, DOS reentrancy doesn't matter.

The static data used by the library functions is the only issue here.

> The driving force behide the questioning is whether DJGPP would be possible
> environment for Real time development, there is no simple answer.   As 
> i386 compiler  I would say yes, but the runtime environment needs work.

Perhaps you could fix the library functions that prevent multithreading, 
and submit the changes for inclusion in a future release of DJGPP.

- Raw text -