Unbuffered channel default select wait time

[Andrew_Stratton]

I’m sure I am doing something stupid here - but I can’t see it :

It seems that the default select (from an unbuffered channel) has a timeout that I can’t avoid.

I have the following init() :

func init() {
	moves = make(moveChannel, 0)
	go updateRelativeMove(moves)
}

Then I have this update :

func updateRelativeMove(moves moveChannel) {
	move_pair := newMovePair()
	for {
		select {
		case new_move := <-moves:
			if new_move.x != nil {
				move_pair.x = new_move.x
			}
			if new_move.y != nil {
				move_pair.y = new_move.y
			}
			fmt.Println("<-", *move_pair.x, *move_pair.y)
		default:
			interval(move_pair)
			time.Sleep(INTERVAL)
		}
	}
}

Where INTERVAL is const INTERVAL = time.Duration(time.Second / 30) and and I have checked the runtime value as well - it is reported as ‘33.333333ms’, i.e. 0.033 secs or 1/30th second.

What happens is that my interval gets called ~15 times a second and so the updates are (of course) calculated wrong - but I expect this to be ~30 times a second. Note that this is when the first case is not matched - i.e. no messages are received from the channel.

I could calculate (at runtime) the time since the last interval - but this shouldn’t be necessary - interval should be called 30 times a second - my only thought is that the unbuffered message read is itself taking the rest of the time - even though that is only about 15 calls a second?!

Note: If I change the interval to 1/60th seconds I get ~38 calls/second

Any help please - best wishes - Andy

[Andrew_Stratton]

Ok - I fixed it - here in case it helps anyone

I changed the default to:

		case <-time.After(INTERVAL):
			interval(move_pair)
		}

and re-measured my timing a bit better (stop watch) - and this works…

[Andrew_Stratton]

Further to the above - it seems that RobotGo is introducing delays of up to 327.1859ms - presumably C taking over the Windows thread…

[Andrew_Stratton]

I solved this - there is a small OS delay (e.g. 25% delay - so worth calculating elapsed time) and a larger delay due to my code

[falco467 (Falco Wockenfuß)]

On a multi-threaded system there are a myriad of things which can happen influencing the timing of execution. Other threads, drivers, timing interrupts, garbage collector, kernel-activities, AV-scans, page-faults, disk-access,… can all drastically change your timings on a real world system.

All modern game engines use a timer to calculated the actual elapsed time since the last update and don’t rely on fixed values.