- 1
- 2
- 3
- 4
Currently, we're ignoring failures to mlock signal stacks in the
workaround for #35777. This means if your mlock limit is low, you'll
instead get random memory corruption, which seems like the wrong
trade-off.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−1
Currently, we're ignoring failures to mlock signal stacks in the
workaround for #35777. This means if your mlock limit is low, you'll
instead get random memory corruption, which seems like the wrong
trade-off.
самый лучший язык на свете продолжает шпарить, отказались от free after use - получили «забыл сделать if (err != nil)»
https://github.com/golang/go/commit/69614c0d0e05787c8203bdc364c3293e1cf5094a
блядь
блядь
блядь
https://www.youtube.com/watch?list=PL4jag8ijtDPwmF-BRtOrCvhlHSGW3l9D3&v=X4-YmXUtTig
О, кстати, а как эта дрисня была технически реализована? Они в загрузчик JRE/рантайм ноды засунули, чи шо?
пра жаву не знаю. Знаешь такие PicoJava протсы?
«PicoJava» поглядел, выглядит круто. Почти как «Лисп-машина».
Go-спода нашли бажину с покоцаной памятью, которая оказалась бажиной в ядре лялиха и которую они до фикса в ядре закрыли костылём, который поломал другие нежные части тела. Я правильно понял?
P.S. Коммент понравился: The random corruption can occur with any program in any language. Using async preemption does make the random corruption more likely. But it can happen regardless.
Азаза, мы все умрём. Коммитовирус