Date: Mon, 26 Mar 2007 00:57:31 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: deeptech71@gmail.com Cc: freebsd-chat@freebsd.org Subject: Re: 64bit timestamp Message-ID: <20070325215731.GA1517@kobe.laptop> In-Reply-To: <4606D88E.4080503@gmail.com> References: <200703251900.l2PJ0Z8w058298@lurza.secnetix.de> <4606D88E.4080503@gmail.com>
index | next in thread | previous in thread | raw e-mail
On 2007-03-25 22:16, deeptech71@gmail.com wrote: >Oliver Fromme wrote: >> Ideally, two consecutive, non-parallel operations should give >> two different timestamps. That applies to creating or >> touching a file or other kind of resource, or even just >> calling the gettimeofday() function from within the same >> thread, or whatever. In reality that isn't the case today for >> FreeBSD for other reasons, but the timestamp accuracy of UFS2 >> would certainly be sufficient for that. > > Actually, my intend wasn't to use it in filesystems, but > server-client apps, such as games, where 32bit integer timers > must be restarted every 3 weeks That's a bug in the applications themselves. The gettimeofday() call in any modern UNIX returns a `struct timeval', which contains *both* a time_t value of the current time with second-level accuracy and a tv_usec member with millisecond accuracy (or at least an approximation of a timestamp with millisecond accuracy). Any userlevel application which uses userlevel time counters and requires a restart every two or three weeks, because these userlevel timecounters have rolled back to zero, is broken and should be fixed.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070325215731.GA1517>