Damien Neil

Regarding overriding the `time` package vs. providing a testing implementation: The `time` package provides a number of commonly-used, exported functions, where code that makes direct use of these functions cannot...

> @neild will it also wait for time.AfterFunc(...) goroutines if time.AfterFunc(...) was called in the chain leading to synctest.Run? Yes, if you call `AfterFunc` from within a synctest group then...

> Given the fake time implementation, if you sleep even a nanosecond past timer expiry, aren't you already guaranteed that those timers will have run because the fake time won't...

> What I am worried about is the unexpected failure modes, leading to undetected regressions, which might need tight support in the testing package to detect. Can you expand more...

``` func TestWait(t *testing.T) { synctest.Run(func() { synctest.Wait() }) } ``` This should succeed. Perhaps the `Wait` documentation would be more clearly phrased as: ``` // Wait blocks until every...

What's the use case for supporting multiple simultaneous `Wait` calls? I think I'd want to see a concrete example before attempting to define semantics.

I tried my hand at implementing the runtime changes: https://go.dev/cl/591997 I have no idea what I'm doing in the runtime, so this implementation is likely mostly or all wrong, but...

`WaitIdle` as proposed here is global. I think that anything we provide should be scoped to a specific set of goroutines, so that tests can be isolated from one another....

> These two seem to be in conflict for a goroutine that does

Filed #67434 with an alternate idea, covering both idle detection and fake timers.