Date:	Wed, 28 Jun 2000 16:46:56 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
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:	<Pine.SUN.3.91.1000628163903.904A-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -