Mail Archives: djgpp-workers/2001/08/17/05:33:45
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
- Raw text -