Hector Martin

The first time I tried using Go I ran into a FFI bug which took 2 days to find and fix (after the Go devs had been unable to figure it out for months) and then a month of bureaucracy to get merged. I didn't write any more Go after that (and after seeing the guts of the runtime).

Then I still had to find and debug *another* Go runtime bug after unfortunately running into random segfaults in a piece of software I used that was written in go. The root cause turned out to be Go devs knowingly making invalid ABI assumptions **to avoid using their slow FFI**.

Because on Linux... surprise! gettimeofday is not a syscall if you want to be fast, it's a call into vDSO, which is just a C ABI call into a special dynamic library that the kernel stuffs into your address space... But actually using Go's C FFI for that would kill the perf.

Wow. And one of the worst parts of that isn't the Go stuff, but the CPU behaviour handling the unmapped write and leaking it to other threads. That sounds like the most "Woah, WTF!" part of all this! Is there any way to consider that sane?

The orq 0 to stack probe still does sound racy though, and likely to provoke strange CPU races.. Not a fan.

There's nothing racy about the orq 0. If the stack is full (on a sane ABI with guard pages), it crashes. That's all.

Yeah sorry, hadn't read your reply yet. Lack of guard page / go stacks right against each other and it makes sense. Still, the lack of atomicity in the orq might have made the compiler authors be wary of that trick...