Date: Wed, 7 Dec 2016 09:51:32 -0800 From: "K. Macy" <kmacy@freebsd.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: Konstantin Belousov <kostikbel@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Help needed to identify golang fork / memory corruption issue on FreeBSD Message-ID: <CAHM0Q_Mg662u9D0KJ9knEWWqi9Ydy38qKDnjLt6XaS0ks%2B9-iw@mail.gmail.com> In-Reply-To: <e160381c-9935-6edf-04a9-1ff78e95d818@multiplay.co.uk> References: <27e1a828-5cd9-0755-50ca-d7143e7df117@multiplay.co.uk> <20161206125919.GQ54029@kib.kiev.ua> <8b502580-4d2d-1e1f-9e05-61d46d5ac3b1@multiplay.co.uk> <20161206143532.GR54029@kib.kiev.ua> <e160381c-9935-6edf-04a9-1ff78e95d818@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHM0Q_Mg662u9D0KJ9knEWWqi9Ydy38qKDnjLt6XaS0ks%2B9-iw>