Mail Archives: djgpp-workers/2001/08/14/12:53:43
> I tested that on PIII 700 (about 2ms to scan descriptors twice and 10
> ms to run a executable) and on a slow 486DX2 66 (about 15ms and
> 170 ms).
So if we can cut the number we scan by some rule (I'm sure we can cut
it by a factor of 100 or so) then it's negligible.
> Tried to put LAR into loop (inline assembler) and got time down from
> 1 ms to about 0.75 ms
Not worth it then.
> Perhaps we could use _my_ds() % 7 as start value
That or the return value from the idea below.
> We can also allocate 2 descriptors before and after spawning
> executable and free all between that was free before spawning
> (it's more safe as doing it blindly)
This was exactly my thoughts, but we don't know how far to go
for the map (I'd like to avoid the entire 8192 calls).
How's this:
1) Allocate a selector
2) Scan the values <adjustable number, say 100> higher than this value,
create a map. (only if not NT, maybe other tests).
3) Do the exec call
4) Allocate selector 2
5) If map: If selector 2 in map range wonderful. If not increase size of
adjustable number for next time. Free selectors via map.
If no map: free selectors between the two allocated values.
Other things I've found:
You can use get_descriptor on WinNT and 2K to get the entire thing
(I planned to do a full map scan of the 8192 and log all diffs to
try and find if there is a leakage of selectors for allocation of
DOS memory blocks as a diagnostic/learning test)
WinNT and 2K show selectors not present if they have never been used
(so you can get an idea of the upper limit touched and don't need
to waste time going higher).
- Raw text -