A
какой конкретно возможности нет? Прибить горутину к треду?
Угу, прибить.
Size: a a a
2020 January 16
VL
Угу, прибить.
она есть
VL
A
А перешедулить на другой тред?
VL
А перешедулить на другой тред?
A
Насколько я понял согласно
https://stackoverflow.com/questions/8378092/issue-with-runtime-lockosthread-and-runtime-unlockosthread/8378536#8378536
нет возможности прибить несколько горутин к одному и тому же физ треду так, чтобы для этой пачки горутин не было нужды использовать мьтексы или каналы. А этого очень хотелось бы в некоторых сценариях
https://stackoverflow.com/questions/8378092/issue-with-runtime-lockosthread-and-runtime-unlockosthread/8378536#8378536
нет возможности прибить несколько горутин к одному и тому же физ треду так, чтобы для этой пачки горутин не было нужды использовать мьтексы или каналы. А этого очень хотелось бы в некоторых сценариях
VL
Насколько я понял согласно
https://stackoverflow.com/questions/8378092/issue-with-runtime-lockosthread-and-runtime-unlockosthread/8378536#8378536
нет возможности прибить несколько горутин к одному и тому же физ треду так, чтобы для этой пачки горутин не было нужды использовать мьтексы или каналы. А этого очень хотелось бы в некоторых сценариях
https://stackoverflow.com/questions/8378092/issue-with-runtime-lockosthread-and-runtime-unlockosthread/8378536#8378536
нет возможности прибить несколько горутин к одному и тому же физ треду так, чтобы для этой пачки горутин не было нужды использовать мьтексы или каналы. А этого очень хотелось бы в некоторых сценариях
смена горутины сравнима по времени с мьютексом. Зачем эта микроортимизация?
A
смена горутины сравнима по времени с мьютексом. Зачем эта микроортимизация?
Дело не в микрооптимизации. А в желании исключить такой тип ошибок как "deadlock" как класс
TS
Дело не в микрооптимизации. А в желании исключить такой тип ошибок как "deadlock" как класс
taskset -c 0 your-go-utility --options
:)
A
taskset -c 0 your-go-utility --options
:)
Я думал что этот секрет Яндекс.Такси под NDA 😂
p
смена горутины сравнима по времени с мьютексом. Зачем эта микроортимизация?
больно оказаться на другом ядре
GG
больно оказаться на другом ядре, когда память вообще далеко-далеко
p
больно оказаться на другом ядре, когда память вообще далеко-далеко
ну да, numa
p
но даже в пределах одного кристалла это ощутимо
p
Насколько я понял согласно
https://stackoverflow.com/questions/8378092/issue-with-runtime-lockosthread-and-runtime-unlockosthread/8378536#8378536
нет возможности прибить несколько горутин к одному и тому же физ треду так, чтобы для этой пачки горутин не было нужды использовать мьтексы или каналы. А этого очень хотелось бы в некоторых сценариях
https://stackoverflow.com/questions/8378092/issue-with-runtime-lockosthread-and-runtime-unlockosthread/8378536#8378536
нет возможности прибить несколько горутин к одному и тому же физ треду так, чтобы для этой пачки горутин не было нужды использовать мьтексы или каналы. А этого очень хотелось бы в некоторых сценариях
синхронизация все равно нужна будет, даже если в 1 потоке, т.к. переключение между горутинами мы не контролируем
A
синхронизация все равно нужна будет, даже если в 1 потоке, т.к. переключение между горутинами мы не контролируем
Не знаю где у вас "все равно нужна будет", у меня в плюсах я всегда знаю где будет отдано управление моему рантайму, заведующему сопрограммами.
Да и в Go, если речь о нём, вряд ли есть техническая возможность переключить лёгкий поток в точках, отличных от мест ввода-вывода, вызова стороннего кода и кода выполняемого на другом физ-треде. Т.е, между
Да и в Go, если речь о нём, вряд ли есть техническая возможность переключить лёгкий поток в точках, отличных от мест ввода-вывода, вызова стороннего кода и кода выполняемого на другом физ-треде. Т.е, между
var i, j int = 1, 2
k := 3
c, python, java := true, false, "no!"
горутина не имеет возможности переключиться, так как там управление рантайму не передаётсяIB
Не знаю где у вас "все равно нужна будет", у меня в плюсах я всегда знаю где будет отдано управление моему рантайму, заведующему сопрограммами.
Да и в Go, если речь о нём, вряд ли есть техническая возможность переключить лёгкий поток в точках, отличных от мест ввода-вывода, вызова стороннего кода и кода выполняемого на другом физ-треде. Т.е, между
Да и в Go, если речь о нём, вряд ли есть техническая возможность переключить лёгкий поток в точках, отличных от мест ввода-вывода, вызова стороннего кода и кода выполняемого на другом физ-треде. Т.е, между
var i, j int = 1, 2
k := 3
c, python, java := true, false, "no!"
горутина не имеет возможности переключиться, так как там управление рантайму не передаётсясопрограммы здесь это корутины или фьючеры? у корутин вроде нет рантайма
https://youtu.be/j9tlJAqMV7U
https://youtu.be/j9tlJAqMV7U
GG
> у корутин вроде нет рантайма
в голанге есть ?
в голанге есть ?
A
сопрограммы здесь это корутины или фьючеры? у корутин вроде нет рантайма
https://youtu.be/j9tlJAqMV7U
https://youtu.be/j9tlJAqMV7U
Что сопрограммы(coroutines), что корутины, что gorutine'ы всё одно и то же - это функции, которые могут в любой точке засуспендиться(выйти наружу, передав управление какому-то другому коду без разрушения локальных переменных) и зарезюмиться, вернувшись в ту же точку, откуда ранее засуспендились через yield-подобный вызов.
p
Не знаю где у вас "все равно нужна будет", у меня в плюсах я всегда знаю где будет отдано управление моему рантайму, заведующему сопрограммами.
Да и в Go, если речь о нём, вряд ли есть техническая возможность переключить лёгкий поток в точках, отличных от мест ввода-вывода, вызова стороннего кода и кода выполняемого на другом физ-треде. Т.е, между
Да и в Go, если речь о нём, вряд ли есть техническая возможность переключить лёгкий поток в точках, отличных от мест ввода-вывода, вызова стороннего кода и кода выполняемого на другом физ-треде. Т.е, между
var i, j int = 1, 2
k := 3
c, python, java := true, false, "no!"
горутина не имеет возможности переключиться, так как там управление рантайму не передаётсяв го переключимся на io, сне, мьютексах, sync.Cond и каналах