Reference:
https://blog.golang.org/playground
In go-playground, code removing of the GOMAXPROCS causes things to execute serially- which is fine according to the spec - but it does make demonstrating certain concurrency structs/problems pretty difficult.
Go playground has these Core functionality such as
implemented as fake functionalities.
when really the sleeps take no time at all. (in time fake implement, advanced the sleep time by observing which time.sleep has the minimum sleep time and advance to it)
To explain the trick we first need to understand how the scheduler manages sleeping goroutines.
Original time.Sleep works:
When a goroutine calls time.Sleep (or similar) the scheduler adds a timer to a heap of pending timers and puts the goroutine to sleep.
Meanwhile, a special 'timer goroutine' manages that heap.
When the 'timer goroutine' starts it tells the scheduler to wake it
when the next pending timer is ready to fire and then sleeps.
When it wakes up it checks which timers have expired,
wakes the appropriate goroutines, and goes back to sleep.
The trick is to change the condition that wakes the 'timer goroutine'.
Instead of waking it after a specific time period, we modify the scheduler to wait for a deadlock; the state where all goroutines are blocked.
The playground version of the runtime maintains its own internal clock.
When the modified scheduler detects a deadlock it checks whether any timers are pending.
If so, it advances the internal clock to the trigger time of the earliest timer and then wakes the 'timer goroutine'.
Execution continues and the program believes that time has passed, when in fact the sleep was nearly instantaneous.
These changes to the scheduler can be found in proc.c and time.goc.
https://blog.golang.org/playground
In go-playground, code removing of the GOMAXPROCS causes things to execute serially- which is fine according to the spec - but it does make demonstrating certain concurrency structs/problems pretty difficult.
Go playground has these Core functionality such as
- time,
- the network,
- and the file system
implemented as fake functionalities.
Go 1.3 Native Client Support Design doc:
https://docs.google.com/document/d/1oA4rs0pfk5NzUyA0YX6QsUEErNIMXawoscw9t0NHafo/pubFake time:
By using a clever trick we can make a Go program think that it is sleeping,when really the sleeps take no time at all. (in time fake implement, advanced the sleep time by observing which time.sleep has the minimum sleep time and advance to it)
To explain the trick we first need to understand how the scheduler manages sleeping goroutines.
Original time.Sleep works:
When a goroutine calls time.Sleep (or similar) the scheduler adds a timer to a heap of pending timers and puts the goroutine to sleep.
Meanwhile, a special 'timer goroutine' manages that heap.
When the 'timer goroutine' starts it tells the scheduler to wake it
when the next pending timer is ready to fire and then sleeps.
When it wakes up it checks which timers have expired,
wakes the appropriate goroutines, and goes back to sleep.
The trick is to change the condition that wakes the 'timer goroutine'.
Instead of waking it after a specific time period, we modify the scheduler to wait for a deadlock; the state where all goroutines are blocked.
The playground version of the runtime maintains its own internal clock.
When the modified scheduler detects a deadlock it checks whether any timers are pending.
If so, it advances the internal clock to the trigger time of the earliest timer and then wakes the 'timer goroutine'.
Execution continues and the program believes that time has passed, when in fact the sleep was nearly instantaneous.
These changes to the scheduler can be found in proc.c and time.goc.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.