X-Authentication-Warning: new-smtp1.ihug.com.au: Host p8-max51.syd.ihug.com.au [203.173.144.200] claimed to be acceleron Message-ID: <005201c12704$e5ee80d0$0a02a8c0@acceleron> From: "Andrew Cottrell" To: , "Eli Zaretskii" , References: <10108162209 DOT AA13700 AT clio DOT rice DOT edu> (sandmann AT clio DOT rice DOT edu) <3B7D0F21 DOT 25494 DOT 2689A4 AT localhost> Subject: Re: _open.c commit? (was Re: Selector Exhaustion) Date: Fri, 17 Aug 2001 20:10:51 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Reply-To: djgpp-workers AT delorie DOT com > > > 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 My 2 cents worth: 1) Are we more interested in speed or stability? In the past I have always gone for stability first and then speed. It it working and then make it fly. 2) Need to do nothing new on DOS or DOSEMU/FREEDOS at the moment until these are further tested / tested etc... 3) Current code improves the ability to compile a large number of files uinder make, such as LIBC. 4) Current code allows you to get further in a build on Win 2K. 5) Need to test changes on : a) vanila DOS b) Linix DOSEMU ( or is it freedos now??) c) Other non standard OS's (not DOS, DOSEMU, 9x, NT 4, 2000 or XP) If my 2 cents makes sense then the way to go would be: 1) Add code to do nothing new under DOS, DOSEMU/FREEDOS and non Win9x/NT/2000/XP 2) Commit the changes once the code is done for DOS, DOSEMU/FREEDOS and non Win9x/NT/2000/XP 3) Keep working on a final solution so that there are no known leaks on OS's that DJGPP works on. Then either a or b or both: a) Improve stability under Win 2K one this is done b) Improve speed. The real issue as far as I can see is stability V's speed. Let me know ASAP if I have made a mistake with this one so I can give my 2 cents to charity.