Я в этом своём гугле, при всех его достоинствах, кажется, немного отстал от жизни: стал мало общаться с функциональным сообществом, меньше читать книжек и разных блогов, и т.п
( Read more... )
Правильно ли я понимаю, что "нативные зелёные нитки" идейно близки goroutines, но сделаны прямо на уровне ядра, а не диспетчера ниток из Go? Соотв. блокирующие вызовы подправлены в libc, чтобы работать с такими нитками, а не с процессами? Интересно, что сделано со стеком; в Go для создания сотен тысяч мелких ниток применяется крошечный стек, наращиваемый по запросу. Тут, кажется, не только libc придётся поправить.
(Да, мне ужасно лень смотреть видео; поищу слайдов.)
Как я запомнил - в ядро добавлена совсем капелька поддержки, позволяющая, грубо говоря, свопить ядрёный контекст двух настоящих ниток. Больше ядра ничего не касается - просто иногда нитки свопятся без ведома ядра. Продолжают работать всякие блокирующие операции; продолжают работать все тулы, расчитывающие найти стектрейс и локальные переменные в привычных местах (дебаггеры, профайлеры); продолжают работать thread-local примитивы; продолжает периодически просыпаться и успешно работать preemptive scheduler; и т.п
( ... )
еще раз. если мы говорим про механизм, обеспечивающий реализацию сопрограмм, то решение гугла очень спорное. да, здорово, что оно видится как обычные треды, но все это сделано как хак в ядре линукса. при этом есть переносимые user land решения (см. boost context), которые, к тому же, работать будут еще быстрее, потому что нет накладных расходов на создание честного потока на уровне ОС, плюс операция переключения не требует вызова ядра (вызов этот относительно дешевый, но все равно не бесплатный).
ну а сгородить огород поверх сопрограмм со своим блекджеком и шлюхами -- отдельная большая песня. это могут быть те механизмы, которые есть в языке Go или тот же boost coroutines. кому что больше нравится.
> здорово, что оно видится как обычные треды Так в этом весь смысл! В этом вся разница между "решением, применимым для какой-нибудь конкретной задачи" и "решением, которое можно полностью прозрачно встроить в базу из полумиллиарда строк кода на С++ и сопутствующих сотен или тысяч различных инструментов, использующихся десятками тысяч инженеров".
Естественно, между переносимостью на ОС, не использующие linux kernel (как я понимаю, они это собираются законтрибьютить в ядро), и этим, выбрали это.
> нет накладных расходов на создание честного потока Тут обычно тоже нет - реюзаются. Создание фибера стоит практически столько же, сколько раньше стоило добавить колбек в thread pool.
насчет "прозрачно встроить" -- громко сказано. что получилось -- избежать накладных расходов планировщика ядра. это не big deal. что не получилось -- заставить работать в новой парадигме старый код. ну просто потому, что дернешь ты какой-то recv() заблокируешь трэд и окажешься в том самом планировщике ядра, от которого ты хотел сбежать.
(Да, мне ужасно лень смотреть видео; поищу слайдов.)
Reply
Reply
если мы говорим про механизм, обеспечивающий реализацию сопрограмм, то решение гугла очень спорное.
да, здорово, что оно видится как обычные треды, но все это сделано как хак в ядре линукса. при этом есть переносимые user land решения (см. boost context), которые, к тому же, работать будут еще быстрее, потому что нет накладных расходов на создание честного потока на уровне ОС, плюс операция переключения не требует вызова ядра (вызов этот относительно дешевый, но все равно не бесплатный).
ну а сгородить огород поверх сопрограмм со своим блекджеком и шлюхами -- отдельная большая песня. это могут быть те механизмы, которые есть в языке Go или тот же boost coroutines. кому что больше нравится.
Reply
Так в этом весь смысл! В этом вся разница между "решением, применимым для какой-нибудь конкретной задачи" и "решением, которое можно полностью прозрачно встроить в базу из полумиллиарда строк кода на С++ и сопутствующих сотен или тысяч различных инструментов, использующихся десятками тысяч инженеров".
Естественно, между переносимостью на ОС, не использующие linux kernel (как я понимаю, они это собираются законтрибьютить в ядро), и этим, выбрали это.
> нет накладных расходов на создание честного потока
Тут обычно тоже нет - реюзаются. Создание фибера стоит практически столько же, сколько раньше стоило добавить колбек в thread pool.
Reply
что получилось -- избежать накладных расходов планировщика ядра. это не big deal.
что не получилось -- заставить работать в новой парадигме старый код. ну просто потому, что дернешь ты какой-то recv() заблокируешь трэд и окажешься в том самом планировщике ядра, от которого ты хотел сбежать.
Reply
Reply
в смысле их внутренний?
Reply
Reply
Leave a comment