In playing with writing some Go code (and not working on the NetBSD port!) I wanted to use some functionality that was in libc.
Now, I know that the Go developers don’t want to link in libc: quite why I’m not sure (I am confident they have their reasons, and can think of several good ones) but it presents a problem: when an OS vendor exposes functionality only as an API in libc, one is left using cgo to access it.
Worse, while I respect what cgo manages, I hit its limits pretty easily, and one limit isn’t at all easy to deal with: indeed, I don’t think it can be dealt with without support from the Go runtime. That case is errno. Regrettably, there are some libc functions that require clearing errno before calling the function, and checking it again afterward. Not good design but enshrined in history and in POSIX, so we’re kinda stuck with it now.
I thought about this for a while, and then realised that the problem is intractable outside the Go runtime, as Go multiplexes multiple goroutines onto individual OS threads, and errno is a per-thread (not, currently at anyrate) a per-goroutine variable.
I imagine the same problems will arise with any APIs which use thread local storage.
Bottom line: Unix errno and threads barely play together, and for the moment at least the Go runtime sweeps the problem under the carpet. Which may be the most sensible thing to do.