Make WASI deterministic

[kabiroberai]

At the moment it seems like there are two sources of nondeterminism in WASI:

1. The random number generator, which is hardcoded to swift_stdlib_random
2. The clocks, hardcoded to the real system clocks

What if we allowed these to be overridden by user-provided Swift.RandomNumberGenerator and Swift.Clock types respectively? We could default to SystemRandomNumberGenerator and ContinuousClock + SuspendingClock.

To my understanding, enabling these to be overridden would allow for fully deterministic execution of WASI binaries while also serving as Dependency Injection points for solid testability.

[kabiroberai]

Tangentially I just realized there's a bug with the SystemExtras.Clock.resolution() implementation: it should be calling _resolution() but it's calling _currentTime() instead:

WasmKit/Sources/SystemExtras/Clock.swift

Lines 65 to 68 in 3adfdb3

	@_alwaysEmitIntoClient
	public func resolution() throws -> Clock.TimeSpec {
	try _currentTime().get()
	}

[kateinoigakukun]

Thanks! I added WallClock, MonotonicClock, and RandomBufferGenerator protocols because stdlib's protocol APIs don't expose enough ability to implement WASI.

[kabiroberai]

Looks great, ty! Unsure if clocks and RNG were the only sources of nondeterminism but if so feel free to close this issue!

[kateinoigakukun]

We still have nondeterminism for NaN payload bit pattern after fp operations, but wouldn't be a problem for most cases

[kabiroberai]

Yeah, nondeterminism in NaN bit patterns is mentioned as an exception in the design spec so I think that's fair game.

[kabiroberai]

stdlib's protocol APIs don't expose enough ability to implement WASI

btw any _Concurrency.Clock that uses the basic _Concurrency.Duration should expose enough API surface (via Duration.components) but I agree that using our own protocol makes sense since Clock has availability restrictions. Also agree with the custom RandomBufferGenerator as an optimization; the default conformance definitely helps.

[kateinoigakukun]

btw any _Concurrency.Clock that uses the basic _Concurrency.Duration should expose enough API surface (via Duration.components)

The problem here is no Instant.zero definition. Without that, we cannot get a duration from zero (UNIX epoch) to now 😢