From owner-freebsd-current  Fri Sep  6 12:31:26 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id MAA21438
          for current-outgoing; Fri, 6 Sep 1996 12:31:26 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA21432
          for <freebsd-current@FreeBSD.ORG>; Fri, 6 Sep 1996 12:31:21 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA13881; Sat, 7 Sep 1996 05:26:36 +1000
Date: Sat, 7 Sep 1996 05:26:36 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199609061926.FAA13881@godzilla.zeta.org.au>
To: freebsd-current@FreeBSD.ORG, j@uriah.heep.sax.de
Subject: Re: fixing accesses to volatile variable `time'
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>pcvt references the `time' variable for the only purpose to avoid
>rescheduling the screen saver more than once per second.  I would
>consider access of this kind being too less important to muck with the
>ipl.  (Nothing bad happens when the clock interrupt occurs inmidst
>this test.)

I noticed similar cases in the networking code.  These cases could use
a macro sloppytime().  This would normally be defined as time.tv_sec.
It usually gives the current time in seconds, but callers must be
prepared for it quite often being wrong by -1 and sometimes being
random.

pcvt mucks with the ipl anyway.  It misuses splhigh().  It should use
spltty() for its own stuff and splclock() if it really cares about
the time.

Bruce