oo
В том, что в 99% случаев мне это мешает? В том, что во многих случаях это бьет по производительности?
А есть какие-то тесты где видно падение производительности ? Как ты это обнаружил ?
Size: a a a
2019 December 16
ZK
А есть какие-то тесты где видно падение производительности ? Как ты это обнаружил ?
Тебе сказали, что данные у потоков не общии, т.е их нужно копировать и это самое бьёт по производимости
ZK
Сделали бы это опцией отключаемой — вопросов не было б
Пул реквест напиши.
KD
Пул реквест напиши.
Там на деле все еще и на GC завязано... он однопоточный, хех...
ZK
Там на деле все еще и на GC завязано... он однопоточный, хех...
Странно. Хотя должно быть наоборот. Т.е. ты писал им?
KD
Странно. Хотя должно быть наоборот. Т.е. ты писал им?
Не-не
KD
Именно потому что он однопоточный, память у тредов независима
KD
Ну, это не главная причина, но одна из.
KD
В таком случае в каждом треде работает свой однопоточный gc и о других потоках знать не знает и ведать не ведает
ZK
В таком случае в каждом треде работает свой однопоточный gc и о других потоках знать не знает и ведать не ведает
ну значит нужно писать им, чтобы они сделали так, чтобы появилась у нас область памяти глобальная и что бы там работал свой gc
KD
Чтоб GC работал более чем с одним потоком ему рано или поздно приходится останавливать все потоки
KD
Как делает GC в Go в том числе
g
В таком случае в каждом треде работает свой однопоточный gc и о других потоках знать не знает и ведать не ведает
Тк а как он собирает в них мусор?
KD
Тк а как он собирает в них мусор?
В каждом треде он свой
KD
И пока в одном треде GC собирает мусор, все остальные работают как ни в чем ни бывало
KD
Или тоже стоят в GC
ZK
В каждом треде он свой
значит плохо он(gc) организован
KD
Но тут уж чисто совпадение может быть
KD
значит плохо он(gc) организован
Ну, это простое и лаконичное решение stop-the-world проблемы
KD
Да и для какого-то многопоточного сервера запросов решение самое подходящее