> 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.
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?
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...
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?