Skip site navigation (1)Skip section navigation (2)
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070325215731.GA1517>