From:	"Yury A. Zaitsev" <yurick AT oblik DOT dp DOT ua>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: __djgpp_map_physical_memory - some questions
Date:	Fri, 15 Jun 2001 18:33:53 +0300
Organization:	Apex NCC Public InterNet News Server
Lines:	31
Message-ID:	<1t9dg9.6k1.ln@nix-if1>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1010614111902 DOT 972S-100000 AT is>
NNTP-Posting-Host:	dialup113.apex.dp.ua
X-Trace:	main.apex.dp.ua 992646318 98347 195.24.139.113 (15 Jun 2001 23:05:17 GMT)
X-Complaints-To:	abuse AT apex DOT dp DOT ua
NNTP-Posting-Date:	15 Jun 2001 23:05:17 GMT
User-Agent:	tin/1.5.8-20010221 ("Blue Water") (UNIX) (Linux/2.2.19 (i686))
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Thu, 14 Jun 2001, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:

>> >> Is DOS _really_ so slow?
>> DD> No, but consider that Unix keeps track of the time *as* a time_t, so
>> DD> time() merely reads a number from memory and returns it - a few CPU
>> DD> cycles at best.  DOS, however, uses the hardware realtime clock, so it
>> DD> must convert month/day/year/hour/minute/second/timezone to a time_t
>> DD> each time you need to know what time it is.  The conversion is slow.
>>       Well, but why time() simply not caches this values (month/day/year/
>> hour/minute/second/timezone) (such as Linux kernel does)?

EZ> This is not as simple as it sounds.  You cannot know whether a second
EZ> passed without asking DOS, and you cannot even rely on the timezone
   But I need to ask DOS anyway :). I'll only save some amount of CPU time
because I will not calculate seconds since 1970 every time() call...

EZ> being fixed, because the user can change the value of TZ in the
EZ> environment.
   AFAIR, user must call tzset() anyway, to apply TZ changes...

EZ> Even if you do cache the time for one second, you cannot simply add
EZ> seconds to the previous value of time_t, since the user can change the
EZ> system clock.
   If user changes system clock then cached values will be quite different
from current values. I want only avoid expensive calculating, not int21
calling...

EZ> But if you have specific changes in mind, please send in patches
EZ> (please post them to djgpp-workers AT delorie DOT com).
   Well, I'll try this. Need I patch 2.03 or some newer (alpha?) version?

- Raw text -