<story><title>Fix for Golang runtime memory corruption bug</title><url>https://go-review.googlesource.com/#/c/34835/</url></story><parent_chain><item><author>bsdetector</author><text>I feel this kind of thing should be remembered when people say they&amp;#x27;re going to reinvent decades-old technology.&lt;p&gt;This bug exists because they wanted to reinvent threading so you could have millions of threads, except when you actually use millions of threads for anything non-trivial it doesn&amp;#x27;t actually work out so well.  To do that they couldn&amp;#x27;t use the standard since-1970 fixed stacks so they needed movable&amp;#x2F;growable stacks.  They reinvented exceptions in a way that broke selinux.  They reinvented the memory allocator in a way that breaks ulimit.  They reinvented a javadoc&amp;#x2F;doxygen that&amp;#x27;s less useful.&lt;p&gt;It&amp;#x27;s great to try to improve things, but a lot of times there&amp;#x27;s actually very good reasons for the old ways.</text></item><item><author>LukeShu</author><text>Indeed, the only actual code change is:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    -	sellock(scases, lockorder)
    +	systemstack(func() {
    +		sellock(scases, lockorder)
    +	})
&lt;/code&gt;&lt;/pre&gt;
The rest of the patch is adding&amp;#x2F;changing comments explaining everything.</text></item><item><author>obstinate</author><text>Much of it is reproduced in the comment in the patch.</text></item><item><author>idank</author><text>You weren&amp;#x27;t joking, it is a story. Isn&amp;#x27;t it kind of unfortunate that all this information is in a commit message, that 1) needs to be discovered through git blame, 2) at risk of requiring code archeology if enough lines change, e.g. by moving code around, and 3) is immutable so parts of it cannot be edited in the future?&lt;p&gt;I see this habit in a lot of commit messages and while it is important to convey intent, there are better ways to document your code (either inline, or in this particular case, a wiki page).</text></item><item><author>morecoffee</author><text>One thing I like about rsc (and Austin) is that they have these well explained commit logs that let&amp;#x27;s people follow along at home.  The changes seem like they are well justified and made for posterity.  This change in particular is a story more than it is a 3 LOC fix.</text></item></parent_chain><comment><author>sfifs</author><text>A lot of the choices for Go become clearer when you realize it was primarily built to solve problems of servers and code base at scale.&lt;p&gt;It supports millions of co-routines, not threads. There&amp;#x27;s typically one thread per CPU or so. The key insight is a lot of server type workloads primarily are constrained on I&amp;#x2F;O and multiplexing virtually unlimited co-routines on a thread automatically by the runtime makes for much simpler concurrent server code.&lt;p&gt;Implementing high concurrency server code in almost any other mainstream language is non-trivial. Indeed I originally switched from Python to Go primarily because of that.</text></comment>
<story><title>Fix for Golang runtime memory corruption bug</title><url>https://go-review.googlesource.com/#/c/34835/</url></story><parent_chain><item><author>bsdetector</author><text>I feel this kind of thing should be remembered when people say they&amp;#x27;re going to reinvent decades-old technology.&lt;p&gt;This bug exists because they wanted to reinvent threading so you could have millions of threads, except when you actually use millions of threads for anything non-trivial it doesn&amp;#x27;t actually work out so well.  To do that they couldn&amp;#x27;t use the standard since-1970 fixed stacks so they needed movable&amp;#x2F;growable stacks.  They reinvented exceptions in a way that broke selinux.  They reinvented the memory allocator in a way that breaks ulimit.  They reinvented a javadoc&amp;#x2F;doxygen that&amp;#x27;s less useful.&lt;p&gt;It&amp;#x27;s great to try to improve things, but a lot of times there&amp;#x27;s actually very good reasons for the old ways.</text></item><item><author>LukeShu</author><text>Indeed, the only actual code change is:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    -	sellock(scases, lockorder)
    +	systemstack(func() {
    +		sellock(scases, lockorder)
    +	})
&lt;/code&gt;&lt;/pre&gt;
The rest of the patch is adding&amp;#x2F;changing comments explaining everything.</text></item><item><author>obstinate</author><text>Much of it is reproduced in the comment in the patch.</text></item><item><author>idank</author><text>You weren&amp;#x27;t joking, it is a story. Isn&amp;#x27;t it kind of unfortunate that all this information is in a commit message, that 1) needs to be discovered through git blame, 2) at risk of requiring code archeology if enough lines change, e.g. by moving code around, and 3) is immutable so parts of it cannot be edited in the future?&lt;p&gt;I see this habit in a lot of commit messages and while it is important to convey intent, there are better ways to document your code (either inline, or in this particular case, a wiki page).</text></item><item><author>morecoffee</author><text>One thing I like about rsc (and Austin) is that they have these well explained commit logs that let&amp;#x27;s people follow along at home.  The changes seem like they are well justified and made for posterity.  This change in particular is a story more than it is a 3 LOC fix.</text></item></parent_chain><comment><author>nemothekid</author><text>I&amp;#x27;m not sure what you are implying here. Should we give up on creating a language that can have millions of threads because we might break selinux? Should we give up on programs with millions of threads because someone in the 1970&amp;#x27;s never foresaw that use case?</text></comment>