From: Psilon AT cris DOT com (Avery Lee)
Newsgroups: comp.lang.asm.x86,comp.os.msdos.djgpp,comp.os.msdos.programmer,comp.lang.pascal.borland,alt.msdos.programmer
Subject: Re: Preemptive Multitasking under DPMI
Date: Mon, 28 Oct 1996 23:29:02 GMT
Organization: Concentric Internet Services
Lines: 51
Message-ID: <327540db.667580@news.concentric.net>
References: <5538hu$2ue AT news DOT latnet DOT lv>
NNTP-Posting-Host: cnc101031.concentric.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

nobody AT nowhere wrote:

>We are trying to understand reentrancy issues related to preemptive 
>multitasking under DPMI.  We've read the DPMI specs carefully, but things are 
>not completely clear. We can see three multitasking schemes:
>
>1) BETWEEN DPMI VIRTUAL MACHINES. 
>This appears to be the way multitasking is intended in the DPMI specs.  This 
>is most likely how multitasking is done in Multiuser DOS schemes.  We don't 
>like this, because each multitasking object would have to have it's own copy 
>of DOS, interrupts, etc.  We are dealing with a real-time application were 
>many threads will be alive at any time.

You can't be sure the DPMI client is multitasking and there's no easy way
to tell.

>2) BETWEEN DPMI CLIENTS WITHIN A SINGLE VIRTUAL MACHINE.
>The DPMI specs clearly states that the only way to multitask clients is by 
>passing the time-slice which means non-preemptive scheduling, so that doesn't 
>appear as an option.

The big problem is that you can't walk up the stack to change the return
address to handle preemptive multitasking, since the specs guarantee that
you get a special interrupt stack.  There might be a nasty way to do it by
forcing selectors to limit 0, thus causing a page fault, and then switching
the address in the exception handler, which CAN do the context switch; but
that depends upon the DPMI host to pass page faults to you and I don't
think that's guaranteed.

>3) WITHIN A DPMI CLIENT BY A KERNEL LOCATED OUTSIDE THE DPMI HOST.
>This is what we want. Unfortunately the DPMI host doesn't know about context 
>switching between tasks and it's not supported in the DPMI specs.  The DPMI 
>specs states that the host maintains *one* global host stack which makes it 
>not reentrant.   What we want to achieve does not seem possible without a 
>reentrant DPMI host.   Could we get some comments on this.

This isn't that much of a problem unless you make a lot of DPMI calls; you
can simply shroud them in a wrapper to prevent any re-entrancy problems.

>Is the lack of reentrancy something inherent to all DPMI hosts, or are there 
>DPMI host implementations which are reentrant.  Is there source code available 
>for DPMI server implementations which we might be able to modify to make it 
>reentrant?

Look for source to Tran's PMODE; I think that supports a good deal, if not
all, of the DPMI 0.9 spec on top of VCPI.


- Avery Lee (Psilon AT cris DOT com)
- try my freeware paint program! (alpha 6 ver.) http://www.cris.com/~Psilon