Date: Wed, 28 Jun 2000 16:46:56 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: iuser AT mtts DOT perm DOT ru cc: djgpp AT delorie DOT com Subject: Re: preemption in real mode and stack size In-Reply-To: <200006271442.TAA10706@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 27 Jun 2000 iuser AT mtts DOT perm DOT ru wrote: > The system must have short response time, so it is essential > to preempt task which is in real mode (executes DOS > disk operation, for example). > I want hook RTC realmode interrupt vector and make switching to > protected mode by DPMI raw mode switch function (returned by fn 0x0306). > Thus I can use my protected mode stack, not DPMI's ( PMODE/DJ allows > to do it, but experiments on CWSDPMI gave me indistinct result ). > From my protected mode stack I can switch to another task. > Am I on the right road? I think this is highly DPMI server dependent. I imagine that some servers won't let you switch into PM from an interrupt handler that is itself installed by a PM program. Those servers that will allow this probably treat this as a nested DPMI program case, because the original application (the one which installed the interrupt handler) is still active. In other words, I don't know. > I don't use recursion and deeply nested calls. What minimum > stack size per thread would be sufficient? Try 64K. It's better to measure it, though. > Are there some libc functions, which require such large stack? I don't think library functions need a large stack. Most of the stack is usually eaten up by the application code. You need to be aware that automatic arrays are allocated off the stack, so by defining a small stack you limit the maximum size of an automatic array a thread can use.