From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10108091447.AA13261@clio.rice.edu> Subject: Re: Selector Exhaustion To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii) Date: Thu, 9 Aug 2001 09:47:19 -0500 (CDT) Cc: djgpp-workers AT delorie DOT com In-Reply-To: from "Eli Zaretskii" at Aug 09, 2001 09:23:49 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 > It also assumes all the selectors in between belong to the child program, > and thus are not used anymore. Isn't that a dangerous assumption? I worried about it. Then I did lots of testing and each LDT appeared to be independent, even on W95. So it would only be a problem if we fragment the selectors ourselves. > I'd say post the patch and lets ask people to patch their libraries, > rebuild as many applications which spawn other programs, such as Make, > GCC, Emacs, and Bash, and lets test how well does it work for some > time. Gotta go do real work now, but I'll try to post it before Andrew can try it tomorrow. One enhancement I considered was to not do anything unless the absolute selector number is above some threshold. So, if the DPMI provder doesn't leak you don't take any risk. > This seems to be unlike what happens on Windows 9X, where exiting the > parent application back to COMMAND.COM frees all the selectors. I think this is one reason why build problems are worse on W2K.