From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108141456.AA13336@clio.rice.edu>
Subject: Re: Selector Exhaustion
To: djgpp-workers AT delorie DOT com, pavenis AT lanet DOT lv
Date: Tue, 14 Aug 2001 09:56:27 -0500 (CDT)
Cc: acottrel AT ihug DOT com DOT au (Andrew Cottrell), eliz AT is DOT elta DOT co DOT il
In-Reply-To: <3B790835.21623.13164B@localhost> from "pavenis@lanet.lv" at Aug 14, 2001 11:15:01 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Initially I did some timing:
> checking all descriptors once took about 1 ms on PIII-700 (Win98SE)

This worries me a bit - this means about 1/4 of second on the 386/16
type platform for the two checks around a call.  This could add hours 
to a build on slower machines.

I was hoping to be smarter about the area scanned.  For example,
allocate 1 selector to get a starting point, then scan 50 selectors
above that point (cut time by factor of 400).  We might consider
in-lining the lar call or making a new routine to do a bulk check?

We also can't hard code selectors (like 7 as the start in the example)
since this is bad under non-ring-3 DPMI providers.

Your example looks very much like what I was working on last night :-)