paul@unisoft.UUCP (n) (04/29/88)
I've noticed that gettimeofday() (the A/UX emulation of the BSD system
call) may run slower than many people think (a number of programs - CAP, X
NeWS etc use this heavily), in BSD the timezone information is obtained
from the kernel, in A/UX it must come from disk ..... 5 minutes with adb
shows that if you don't want the timezone information (most applications
do not) the following macro can be used:
#define gettimeofday(time, timezone) _gettimeofday(time)
again this is only a real issue if you call gettimofday a lot (rather than
just once per program)
Paul
--
Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca
E-mail: ..!{ucbvax,hoptoad}!unisoft!paul
Nothing here represents the opinions of UniSoft or its employees (except me)
"Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)guy@gorodish.Sun.COM (Guy Harris) (04/29/88)
> I've noticed that gettimeofday() (the A/UX emulation of the BSD system > call) may run slower than many people think (a number of programs - CAP, X > NeWS etc use this heavily), in BSD the timezone information is obtained > from the kernel, in A/UX it must come from disk ..... 5 minutes with adb > shows that if you don't want the timezone information (most applications > do not) the following macro can be used: > > > #define gettimeofday(time, timezone) _gettimeofday(time) 1) Could not "gettimeofday()" have a static flag that indicates whether it's called "tzset()" or not, so that only the first call to "gettimeofday()" calls "tzset()"? 2) Does not "gettimeofday()" avoid calling "tzset()" at all if "timezone" is NULL? Lots of programs (all the properly-written ones) that call "gettimeofday()" explicitly indicate their disinterest in the timezone information by passing a (properly-case, of course) null pointer as the second argument, and most programs that call "gettimeofday()" don't want the timezone information.
guy@gorodish.Sun.COM (Guy Harris) (04/30/88)
> Lots of programs (all the properly-written ones) that call > "gettimeofday()" explicitly indicate their disinterest in the timezone > information by passing a (properly-case, of course) null pointer as the > second argument, and most programs that call "gettimeofday()" don't want > the timezone information. Before everybody writes in, let me point out that: 1) "properly-case" should be "properly-cast" and 2) the "all the properly-written ones" refers not to all programs that call "gettimeofday()", just the 99% of them that have no interest in getting the time zone information directly from "gettimeofday()". Obviously, a properly written program that *does* want the time zone information from "gettimeofday()" won't pass it a null pointer for the second argument....
paul@unisoft.UUCP (n) (05/01/88)
In article <51320@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: > >1) Could not "gettimeofday()" have a static flag that indicates whether it's > called "tzset()" or not, so that only the first call to "gettimeofday()" > calls "tzset()"? actually it ought to read it, maybe not everytime but at least once every 10-15 minutes (think of a server daemon - like CAP aufs etc that runs for potentially months or years at a time)) just in case the timezone changed (ie those two times twice a year when the daylight-saving changes) > >2) Does not "gettimeofday()" avoid calling "tzset()" at all if "timezone" is yes ... this is a bug and has been reported to "the proper authorities" along with the fix ... > NULL? Lots of programs (all the properly-written ones) that call > "gettimeofday()" explicitly indicate their disinterest in the timezone unfortunately there are some out there that don't :-( Paul -- Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca E-mail: ..!{ucbvax,hoptoad}!unisoft!paul Nothing here represents the opinions of UniSoft or its employees (except me) "Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)
guy@gorodish.Sun.COM (Guy Harris) (05/02/88)
> >1) Could not "gettimeofday()" have a static flag that indicates whether it's > > called "tzset()" or not, so that only the first call to "gettimeofday()" > > calls "tzset()"? > > actually it ought to read it, maybe not everytime but at least once every > 10-15 minutes (think of a server daemon - like CAP aufs etc that runs for > potentially months or years at a time)) just in case the timezone changed > (ie those two times twice a year when the daylight-saving changes) It appears that either 1) you aren't really running the Olson code or 2) don't understand how the Olson code works. The timezone *file* only changes if the government goes bananas and changes the *rules*. It does *not* change twice a year. The "timezone" structure in 4.[23]BSD provides two pieces of information: 1) the *standard* offset from GMT; this does *not* change when DST starts or ends. For example, it's hardwired to 8 hours here. 2) a small integer indicating the set of DST rules to follow. (The latter obviously cannot always be reconstructed from the information in the Olson time zone file. It selects one of a set of hard-coded rule tables; if the current rules match none of the tables, you lose. What we will do in SunOS 4.0 is run a program at boot time that finds the appropriate value for the standard offset and the "best" value of the small integer, given the current default time zone rules, and does a "settimeofday" call (with the first argument a NULL pointer; this sets the time zone information and leaves the time-of-day information alone) to stuff those into the kernel. This permits old programs to work as well as they would have under older versions of the systems; they won't, of course, be able to use the greater flexibility of the Olson scheme.) If you return the standard (non-changing, barring e.g. an earthquake dislodging the stuff west of the San Andreas and sending it many thousands of miles west) offset from GMT in the "tz_minuteswest" field, this obviously doesn't change twice a year. If, instead, you return the current offset from GMT, and return 0 in the "tz_dsttime" field (i.e., pretend that DST is never in effect, but that the standard offset changes twice a year), you still need not reread the file twice a year; you just recompute the offset from GMT at the current time, using the rules you've already read in, and return that.