Hacker News Reader

Java would be disqualified due to GC:

> It is worth noting that Go came nearest disqualifying itself entirely here. If it were not possible to lock out Go’s GC in critical regions Rust would win by default.

View on HN

I think the assumption is that, as ntpsec is "soft real time" i.e. not hard real time, sufficiently low pauses mean you wouldn't need to lock out the GC at all.

I mean, technically anything the system or runtime does on your behalf can be thought of as a 'pause'. What if you lose your timeslice half way through a function?

What technique is used to lock the GC out?

dunno- just copying what was in the original article :)

i'd guess a negative arg passed to https://golang.org/pkg/runtime/debug/#SetGCPercent

I hope not, because this way a critical section requires two non-concurrent GCs (SetGCPercent calls runtime.GC() [1] and runtime.GC() triggers a non-concurrent GC [2]).

If this is the option, I hope the critical sections in ntpsec are few and far apart...

[1] https://golang.org/src/runtime/debug/garbage.go?s=3706:3740#...

[2] https://golang.org/src/runtime/mgc.go?s=33685:33694#L844

Reply on news.ycombinator.com