2009-02-16 17:07:11 -08:00
|
|
|
// Copyright 2009 The Go Authors. All rights reserved.
|
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
|
|
|
|
|
package time
|
|
|
|
|
|
2013-08-28 11:16:55 -07:00
|
|
|
// Sleep pauses the current goroutine for at least the duration d.
|
|
|
|
|
// A negative or zero duration causes Sleep to return immediately.
|
2011-12-12 16:12:22 -05:00
|
|
|
func Sleep(d Duration)
|
|
|
|
|
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
// Interface to timers implemented in package runtime.
|
2016-09-30 19:43:42 -05:00
|
|
|
// Must be in sync with ../runtime/time.go:/^type timer
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
type runtimeTimer struct {
|
2019-04-11 20:23:35 -07:00
|
|
|
pp uintptr
|
2019-04-10 17:38:26 -07:00
|
|
|
when int64
|
|
|
|
|
period int64
|
|
|
|
|
f func(interface{}, uintptr) // NOTE: must not be closure
|
|
|
|
|
arg interface{}
|
|
|
|
|
seq uintptr
|
|
|
|
|
nextwhen int64
|
|
|
|
|
status uint32
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
}
|
|
|
|
|
|
2013-02-26 09:23:58 +11:00
|
|
|
// when is a helper function for setting the 'when' field of a runtimeTimer.
|
|
|
|
|
// It returns what the time will be, in nanoseconds, Duration d in the future.
|
2016-03-01 23:21:55 +00:00
|
|
|
// If d is negative, it is ignored. If the returned value would be less than
|
2013-02-26 09:23:58 +11:00
|
|
|
// zero because of an overflow, MaxInt64 is returned.
|
|
|
|
|
func when(d Duration) int64 {
|
|
|
|
|
if d <= 0 {
|
runtime: use monotonic clock for timers (linux/386, linux/amd64)
This lays the groundwork for making Go robust when the system's
calendar time jumps around. All input values to the runtimeTimer
struct now use the runtime clock as a common reference point.
This affects net.Conn.Set[Read|Write]Deadline(), time.Sleep(),
time.Timer, etc. Under normal conditions, behavior is unchanged.
Each platform and architecture's implementation of runtime·nanotime()
should be modified to use a monotonic system clock when possible.
Platforms/architectures modified and tested with monotonic clock:
linux/x86 - clock_gettime(CLOCK_MONOTONIC)
Update #6007
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, alex.brainman, stephen.gutekanst, dave, rsc, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/53010043
2014-02-24 10:57:46 -05:00
|
|
|
return runtimeNano()
|
2013-02-26 09:23:58 +11:00
|
|
|
}
|
runtime: use monotonic clock for timers (linux/386, linux/amd64)
This lays the groundwork for making Go robust when the system's
calendar time jumps around. All input values to the runtimeTimer
struct now use the runtime clock as a common reference point.
This affects net.Conn.Set[Read|Write]Deadline(), time.Sleep(),
time.Timer, etc. Under normal conditions, behavior is unchanged.
Each platform and architecture's implementation of runtime·nanotime()
should be modified to use a monotonic system clock when possible.
Platforms/architectures modified and tested with monotonic clock:
linux/x86 - clock_gettime(CLOCK_MONOTONIC)
Update #6007
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, alex.brainman, stephen.gutekanst, dave, rsc, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/53010043
2014-02-24 10:57:46 -05:00
|
|
|
t := runtimeNano() + int64(d)
|
2013-02-26 09:23:58 +11:00
|
|
|
if t < 0 {
|
|
|
|
|
t = 1<<63 - 1 // math.MaxInt64
|
|
|
|
|
}
|
|
|
|
|
return t
|
|
|
|
|
}
|
|
|
|
|
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
func startTimer(*runtimeTimer)
|
|
|
|
|
func stopTimer(*runtimeTimer) bool
|
2019-04-10 17:23:05 -07:00
|
|
|
func resetTimer(*runtimeTimer, int64)
|
2009-02-16 17:07:11 -08:00
|
|
|
|
2011-01-25 12:25:48 -08:00
|
|
|
// The Timer type represents a single event.
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
// When the Timer expires, the current time will be sent on C,
|
|
|
|
|
// unless the Timer was created by AfterFunc.
|
2014-10-01 16:44:52 -07:00
|
|
|
// A Timer must be created with NewTimer or AfterFunc.
|
2011-01-25 12:25:48 -08:00
|
|
|
type Timer struct {
|
2011-11-30 11:59:44 -05:00
|
|
|
C <-chan Time
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
r runtimeTimer
|
2010-12-06 14:19:30 -05:00
|
|
|
}
|
|
|
|
|
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
// Stop prevents the Timer from firing.
|
|
|
|
|
// It returns true if the call stops the timer, false if the timer has already
|
2013-01-17 14:41:53 +11:00
|
|
|
// expired or been stopped.
|
2012-11-08 23:25:48 +08:00
|
|
|
// Stop does not close the channel, to prevent a read from the channel succeeding
|
|
|
|
|
// incorrectly.
|
2016-05-31 15:30:52 +10:00
|
|
|
//
|
2019-07-11 00:57:57 +00:00
|
|
|
// To ensure the channel is empty after a call to Stop, check the
|
|
|
|
|
// return value and drain the channel.
|
2016-10-17 23:51:16 -04:00
|
|
|
// For example, assuming the program has not received from t.C already:
|
|
|
|
|
//
|
2016-05-31 15:30:52 +10:00
|
|
|
// if !t.Stop() {
|
|
|
|
|
// <-t.C
|
|
|
|
|
// }
|
2016-10-17 23:51:16 -04:00
|
|
|
//
|
2016-05-31 15:30:52 +10:00
|
|
|
// This cannot be done concurrent to other receives from the Timer's
|
2019-11-19 16:14:50 -08:00
|
|
|
// channel or other calls to the Timer's Stop method.
|
2016-11-11 10:11:19 -05:00
|
|
|
//
|
|
|
|
|
// For a timer created with AfterFunc(d, f), if t.Stop returns false, then the timer
|
|
|
|
|
// has already expired and the function f has been started in its own goroutine;
|
|
|
|
|
// Stop does not wait for f to complete before returning.
|
|
|
|
|
// If the caller needs to know whether f is completed, it must coordinate
|
|
|
|
|
// with f explicitly.
|
2013-01-17 14:41:53 +11:00
|
|
|
func (t *Timer) Stop() bool {
|
2014-10-21 13:26:40 +02:00
|
|
|
if t.r.f == nil {
|
|
|
|
|
panic("time: Stop called on uninitialized Timer")
|
|
|
|
|
}
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
return stopTimer(&t.r)
|
2010-12-06 14:19:30 -05:00
|
|
|
}
|
|
|
|
|
|
2011-01-25 12:25:48 -08:00
|
|
|
// NewTimer creates a new Timer that will send
|
2012-01-07 20:53:53 -05:00
|
|
|
// the current time on its channel after at least duration d.
|
2011-11-30 11:59:44 -05:00
|
|
|
func NewTimer(d Duration) *Timer {
|
|
|
|
|
c := make(chan Time, 1)
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
t := &Timer{
|
|
|
|
|
C: c,
|
|
|
|
|
r: runtimeTimer{
|
2013-02-26 09:23:58 +11:00
|
|
|
when: when(d),
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
f: sendTime,
|
|
|
|
|
arg: c,
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
startTimer(&t.r)
|
|
|
|
|
return t
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-17 14:41:53 +11:00
|
|
|
// Reset changes the timer to expire after duration d.
|
|
|
|
|
// It returns true if the timer had been active, false if the timer had
|
|
|
|
|
// expired or been stopped.
|
2016-05-31 15:30:52 +10:00
|
|
|
//
|
2019-07-11 00:57:57 +00:00
|
|
|
// Reset should be invoked only on stopped or expired timers with drained channels.
|
2016-10-17 23:51:16 -04:00
|
|
|
// If a program has already received a value from t.C, the timer is known
|
2019-07-11 00:57:57 +00:00
|
|
|
// to have expired and the channel drained, so t.Reset can be used directly.
|
2016-10-17 23:51:16 -04:00
|
|
|
// If a program has not yet received a value from t.C, however,
|
|
|
|
|
// the timer must be stopped and—if Stop reports that the timer expired
|
|
|
|
|
// before being stopped—the channel explicitly drained:
|
|
|
|
|
//
|
2016-05-31 15:30:52 +10:00
|
|
|
// if !t.Stop() {
|
|
|
|
|
// <-t.C
|
|
|
|
|
// }
|
|
|
|
|
// t.Reset(d)
|
2016-10-17 23:51:16 -04:00
|
|
|
//
|
2016-05-31 15:30:52 +10:00
|
|
|
// This should not be done concurrent to other receives from the Timer's
|
|
|
|
|
// channel.
|
|
|
|
|
//
|
|
|
|
|
// Note that it is not possible to use Reset's return value correctly, as there
|
|
|
|
|
// is a race condition between draining the channel and the new timer expiring.
|
2016-10-17 23:51:16 -04:00
|
|
|
// Reset should always be invoked on stopped or expired channels, as described above.
|
2016-05-31 15:30:52 +10:00
|
|
|
// The return value exists to preserve compatibility with existing programs.
|
2013-01-17 14:41:53 +11:00
|
|
|
func (t *Timer) Reset(d Duration) bool {
|
2014-10-21 13:26:40 +02:00
|
|
|
if t.r.f == nil {
|
|
|
|
|
panic("time: Reset called on uninitialized Timer")
|
|
|
|
|
}
|
2013-02-26 09:23:58 +11:00
|
|
|
w := when(d)
|
2013-01-17 14:41:53 +11:00
|
|
|
active := stopTimer(&t.r)
|
2019-04-10 17:23:05 -07:00
|
|
|
resetTimer(&t.r, w)
|
2013-01-17 14:41:53 +11:00
|
|
|
return active
|
|
|
|
|
}
|
|
|
|
|
|
2014-09-04 10:04:04 +04:00
|
|
|
func sendTime(c interface{}, seq uintptr) {
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
// Non-blocking send of time on c.
|
|
|
|
|
// Used in NewTimer, it cannot block anyway (buffer).
|
|
|
|
|
// Used in NewTicker, dropping sends on the floor is
|
|
|
|
|
// the desired behavior when the reader gets behind,
|
|
|
|
|
// because the sends are periodic.
|
|
|
|
|
select {
|
runtime: use monotonic clock for timers (linux/386, linux/amd64)
This lays the groundwork for making Go robust when the system's
calendar time jumps around. All input values to the runtimeTimer
struct now use the runtime clock as a common reference point.
This affects net.Conn.Set[Read|Write]Deadline(), time.Sleep(),
time.Timer, etc. Under normal conditions, behavior is unchanged.
Each platform and architecture's implementation of runtime·nanotime()
should be modified to use a monotonic system clock when possible.
Platforms/architectures modified and tested with monotonic clock:
linux/x86 - clock_gettime(CLOCK_MONOTONIC)
Update #6007
LGTM=dvyukov, rsc
R=golang-codereviews, dvyukov, alex.brainman, stephen.gutekanst, dave, rsc, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/53010043
2014-02-24 10:57:46 -05:00
|
|
|
case c.(chan Time) <- Now():
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
default:
|
|
|
|
|
}
|
2011-01-25 12:25:48 -08:00
|
|
|
}
|
|
|
|
|
|
2011-11-30 11:59:44 -05:00
|
|
|
// After waits for the duration to elapse and then sends the current time
|
2010-12-06 14:19:30 -05:00
|
|
|
// on the returned channel.
|
2012-01-07 20:53:53 -05:00
|
|
|
// It is equivalent to NewTimer(d).C.
|
2016-05-20 22:43:14 +00:00
|
|
|
// The underlying Timer is not recovered by the garbage collector
|
|
|
|
|
// until the timer fires. If efficiency is a concern, use NewTimer
|
|
|
|
|
// instead and call Timer.Stop if the timer is no longer needed.
|
2011-11-30 11:59:44 -05:00
|
|
|
func After(d Duration) <-chan Time {
|
|
|
|
|
return NewTimer(d).C
|
2011-01-10 11:51:38 -08:00
|
|
|
}
|
|
|
|
|
|
2011-12-08 15:42:44 +11:00
|
|
|
// AfterFunc waits for the duration to elapse and then calls f
|
2011-01-25 12:25:48 -08:00
|
|
|
// in its own goroutine. It returns a Timer that can
|
|
|
|
|
// be used to cancel the call using its Stop method.
|
2011-12-08 15:42:44 +11:00
|
|
|
func AfterFunc(d Duration, f func()) *Timer {
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
t := &Timer{
|
|
|
|
|
r: runtimeTimer{
|
2013-02-26 09:23:58 +11:00
|
|
|
when: when(d),
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
f: goFunc,
|
|
|
|
|
arg: f,
|
|
|
|
|
},
|
2010-12-06 14:19:30 -05:00
|
|
|
}
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
startTimer(&t.r)
|
|
|
|
|
return t
|
2010-12-06 14:19:30 -05:00
|
|
|
}
|
|
|
|
|
|
2014-09-04 10:04:04 +04:00
|
|
|
func goFunc(arg interface{}, seq uintptr) {
|
runtime: add timer support, use for package time
This looks like it is just moving some code from
time to runtime (and translating it to C), but the
runtime can do a better job managing the goroutines,
and it needs this functionality for its own maintenance
(for example, for the garbage collector to hand back
unused memory to the OS on a time delay).
Might as well have just one copy of the timer logic,
and runtime can't depend on time, so vice versa.
It also unifies Sleep, NewTicker, and NewTimer behind
one mechanism, so that there are no claims that one
is more efficient than another. (For example, today
people recommend using time.After instead of time.Sleep
to avoid blocking an OS thread.)
Fixes #1644.
Fixes #1731.
Fixes #2190.
R=golang-dev, r, hectorchu, iant, iant, jsing, alex.brainman, dvyukov
CC=golang-dev
https://golang.org/cl/5334051
2011-11-09 15:17:05 -05:00
|
|
|
go arg.(func())()
|
2010-12-06 14:19:30 -05:00
|
|
|
}
|