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