Sender: rich AT delorie DOT com
Message-ID: <390DF79D.5B86C867@bigfoot.com>
Date: Mon, 01 May 2000 22:31:09 +0100
From: Richard Dawe <richdawe AT bigfoot DOT com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: 3rd Try: Maybe an asm problem? (Problems linking)
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000501161102 DOT 11049A-100000 AT is> <390D7DD9 DOT F55A5EF6 AT mtu-net DOT ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Hello.

"Alexei A. Frounze" wrote:
> 
> Eli Zaretskii wrote:
> > __dpmi_yield is not for task switching, it's for releasing the current
> > time slice allotted by Windows (or any other multi-tasking scheduler).
[snip]
> Do you bother about that while you're programming? I.e. do you write a
> custom keyboard read function that calls that thing?

FYI libsocket uses __dpmi_yield() a fair amount. It made a significant
difference to libsocket's behaviour when I was testing its Winsock 1
support with internal select() operations with time-outs. Without the
__dpmi_yield() code, my computer was almost unusable, because the DOS box
was hogging all the processor time in a loop in the internal select
operation. libsocket calls WSOCK.VXD a lot, which must be an expensive
operation in processor time.

If you're waiting for some status bit to change in your loop, what's the
point of hogging the processor?

Bye,

-- 
Richard Dawe
richdawe AT bigfoot DOT com ICQ 47595498 http://www.bigfoot.com/~richdawe/