Mail Archives: djgpp-workers/2001/08/17/07:20:29
> > > 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.
- Raw text -