From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <9706121614.AA17254@clio.rice.edu>
Subject: Re: suggestion for moving DTA to fixed place in __tb
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Thu, 12 Jun 1997 11:14:36 -0600 (CDT)
Cc: Vik DOT Heyndrickx AT rug DOT ac DOT be, djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.970612184822.9257g-100000@is> from "Eli Zaretskii" at Jun 12, 97 06:57:05 pm
Content-Type: text
Precedence: bulk

> Unix programs just *love* `stat', even when `access' would do the job, 
> because `stat' is a simple OS call in Unix.

stat is more portable than access is (it's an older, more established call).

There are lots of opportunities for caching some of this information to
avoid the DOS calls - findfirst is called quite a bit.  But it does really
complicate the library and needs a switch to turn off/flush the internal
cache or it breaks programs in some cases on multi-tasking boxes.

> Yes, but some profiling data would be nice.  I have found that unless a 
> program calls `stat' hundreds of times, it is not worth our while to 
> optimize `stat'.  Personally, I find it hard to believe that SetDTA call 
> is eating up any significant amount of cycles, relative to other 
> disk-related functions.

Since a typical box can do about 10K of these mode swaps per second, the
setDTA is probably not a huge issue.  Some of the extra calls the libc makes
are an issue when you are calling readdir/stat 10,000 times, but most of
those can be turned off with a flag.

> > So, why don't we set the DTA address to the start of __tb in crt1.c and
> > leave it there for the rest of the program?
> This is just more dangerous, due to child programs, programs that crash 
> or exit abnormally and don't reset the DTA to its previous address, etc.

I'm not sure it's more dangerous, but I'm not convinced there are any
huge savings in messing with it either.