From: pavenis AT lanet DOT lv To: "Eli Zaretskii" , sandmann AT clio DOT rice DOT edu Date: Fri, 17 Aug 2001 12:33:37 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: _open.c commit? (was Re: Selector Exhaustion) Cc: djgpp-workers AT delorie DOT com Message-ID: <3B7D0F21.25494.2689A4@localhost> In-reply-to: <2561-Fri17Aug2001115601+0300-eliz@is.elta.co.il> References: <10108162209 DOT AA13700 AT clio DOT rice DOT edu> (sandmann AT clio DOT rice DOT edu) X-mailer: Pegasus Mail for Win32 (v3.12c) 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 On 17 Aug 2001, at 11:56, Eli Zaretskii wrote: > > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) > > Date: Thu, 16 Aug 2001 17:09:40 -0500 (CDT) > > > > Should we sit on the current selector cleanup patch or commit it also? > > I think it should be committed and we should ask people to build > applications (such as Make, RHIDE, and Bash) with it and test it in a > variety of environments. I have built make-3.79.1 with such patch and bootstrapped gcc-3.0.1 development versions (from CVS) more than once > However, I'd like to see that patch changed so that plain DOS systems > aren't affected at all. Why slow down systems which don't need that? > We already have the _windows_major variable that can be used to easily > test for whether we are on Windows, and _get_dos_version(1) can be > used for NT/W2K/XP. Ok. But I would not like to rely only on Windows presence. One can try to run DJGPP applications under DOSEMU under Linux and in this case I have seen descriptors leak (as far as I remeber) at least with some versions. We may also have bad DPMI providers for DOS which leaks descriptors. So I would prefer to look whether we have good DPMI server. I still have some questions Is it possible to find whether descriptor is freed under WinNT. As far as I tested freeing doesn't change access rights. Maybe looking whether we can read or write there can help. Otherwise it's easy for badly behaving program (furtunatelly most DJGPP users don't directly mess with allocating LDT descriptors) to run into trouble. I would prefer checking whether selector is actually allocated by child process instead of blindly believing it's using continuous interval of selectors, as it's too easy to break such assumption (and Micro$oft can do it at any time eve without breaking DPMI specs, I think) How it's best to recognize good DPMI servers (like CWSDPMI). maybe we should add some environment variable like WORKAROUND_LDT_DESCRIPTOR_LEAKS=y to enable support of this feature (I'ts currently dangerous for WinNT, Win2K and Win XT, it wastes some time on other systems). About wasted time in Win9X: Perhaps it would be best to build BASH and MAKE with included descriptor leak workaround and compare how big is slowdown for example in real configure scripts and building some packages. Some examples 1) building development version of gcc-3.0.1 takes perhaps less than 8000 processes to run, so 16 seconds slowdown, when total build time is more than an 1 hour on PIII 700 2) configuring development version of gcc-3.0.1 takes less than 2000 processes to run (It never crashed for me due to descriptor leaks if started in a new DOS session. So also the slowdown is only some percents 3) of course spawning program that does nothing in tight loop is worst case and we can have up to 20-30% slowdown in that case Andris