Help needed to identify golang fork / memory corruption issue on FreeBSD

[K. Macy]

> No it doesn't, each built binary its totally standalone and uses asm for
> core system calls.
>
> The runtime directly creates kernel threads with thr_new, which it then
> manages internally.


The thr and umtx syscalls are, in practice, an SPI (service private
interface). They're not well documented, and using them directly is
going to be brittle across releases.

In general, using system calls directly is essentially static linking
which is even out of vogue on Linux and not even permitted on OSX,
Windows, or Solaris. You're creating a program that is only guaranteed
to work for the duration of current ABI guarantees. I understand that
this is one of the things that people *like* about go, but I just
wanted to observe that YMWV.

-M