delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/08/20/02:55:18

Date: Mon, 20 Aug 2001 09:38:43 +0300 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
To: djgpp-workers AT delorie DOT com
Cc: eliz AT is DOT elta DOT co DOT il
Subject: Re: Selector exhaustion code update
In-Reply-To: <10108200342.AA18075@clio.rice.edu>
Message-ID: <Pine.A41.4.05.10108200925540.40970-100000@ieva06.lanet.lv>
MIME-Version: 1.0
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


On Sun, 19 Aug 2001, Charles Sandmann wrote:

> > I'm nervous about calling malloc at that stage.  
> 
> I put it on the stack in this new version.  Turns out to be smaller, 
> simpler (better) code anyway.
> 
> > Also, maybe the comments in the code could be made more explicit about
> > things that are done by each of the options, to avoid maintenance
> > problems in the future.
> 
> Added 3 big blocks of comments and additional line comments.
> 
> There are some other optimizations using the LAR code which can be
> added into the option 2 (NT) section to make it faster which might
> cause us to increase the how_deep parameter.  Andris' code scaned 
> 8192 - this only scans 12 (which may be too few by default).  But
> I would like feedback before futzing with it more.

Perhaps it would be usefull to increase the default. For example
if gcc runs: cpp1.exe, cc1.exe, as.exe, collect2.exe and ld.exe and is not
linked with libc.a where this feature is included we already have more.
If we're compiling more sources when invoking gcc things are even worse.
So I suggest to increase the default to something like 50

Other suggestion:


move 'char desc_map[how_deep]' inside 
	     if (workaround_descriptor_leaks)
block. In this case we can set initial value depending on
workaround type. If we can use LAR then I think it's safe
(and fast enough) to scan at least 100 descriptors. I think
it's better while most DJGPP packages are not rebuilt with
new libc. Scanning 8192 descriptors took about 30% overhead
when spawned program simply quits. I think even 3% would be
acceptable as it would not noticeable in most real life 
situations. Initial value of limit could be reduced in
future when most packages will be built using new libc.a

Andris


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019