@toothrot correct me if I'm wrong, but I believe that the playground sandbox looks like a program from x/playground as init (PID 1), which then launches the actual user binary as a child process.

Since the init process is a Go process, it will not necessary create a consistent number of threads. Each thread takes a PID, so if the number of threads in the parent varies, then the PID of the child will vary.

FWIW, I don't think os.Getpid is something we should guarantee remains consistent across runs. That said, I was under the impression that we cached output to keep it more consistent (plus reduce load). Yet, running https://play.golang.org/p/z12AQN-w-hD several times does yield different results, so perhaps our caching is much less aggressive than I thought?

@prattmic You're correct, here's the actual Dockerfile for the sandbox: https://github.com/golang/playground/blob/master/sandbox/Dockerfile.gvisor, which is started from here: https://github.com/golang/playground/blob/master/sandbox/sandbox.go#L448. --init is not specified, meaning we are indeed PID 1.

The memcached server crashed again. I restarted it, and the responses should be cached.

That being said, I don't think this is an issue otherwise.

Now that it is statistically impossible for a program to have non-deterministic output in the Go playground, it would be unreasonable of me to think this is still an issue.

But it is aesthetically contradictory to have faketime but no fakepid.