The Go runtime scheduler's way of dealing with system calls
This scheduler is probably the most salient feature of Go, but is only indirectly described in the language specification.<p>Perhaps it is just me, but it seems all this user space rigamarole to map bits of execution onto cores points to an overall architecture “smell”.  This should be performed and enabled by the OS.<p>You can see the seams between the OS and the go runtime tear a little whenever a library acquires an ownership lock where the thread id is recorded.  In Go, computation moves freely between threads, so that lock doesn’t work (at least without special instructions to the runtime to lock that goroutine to a thread).<p>The whole POSIX threading model seems broken in this context.