Date: Mon, 20 Aug 2001 09:38:43 +0300 (WET) From: Andris Pavenis 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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