Здравствуйте, so5team, Вы писали:
KP>>UPD. поличтал документацию по Akka и похоже что она тоже фактически на концептах зеленых потоков крутится.
S>А можно с этого места поподробнее? Хотя бы ссылку на документацию по Akka, где это описывается?
Я не прав тут, оказывается спутал с неким Quasar. Akka используют обычный пул потоков и асинхронно обрабатывают сообщения.
Здравствуйте, kaa.python, Вы писали: KP>Почему нам противопоказаны, а Гуглу с Го и Вацапу с Эрлангом нет?
В эрланге, афаик, как раз что-то вроде корутин, а не зелёные потоки. KP>Кстати, а кто по реальным потокам кто будет эти корутины раскидывать?
Ну, а зелёные потоки по реальным потокам раскидывает кто?
Рантайм, вестимо. KP>Шикарный документ! Эрланг они, конечно же забыли упомянуть, слишком успешное решение вышло. Про Го сказали, и в сказаном ключевое то, что подход который использует Го не сработает на C++! KP>
Pointer adjustment is possible to do in a programming language with precise garbage collector, such as Go, but
KP>unfeasible in more traditional languages where it is not possible to freely move objects in memory and adjust all
KP>of the pointers pointing to them
KP>Все остальные моменты относящиеся к неудачам так же сильно завязаны на само модель управления памятью системой. Т.е. все провалы относящиеся к WIndows, Solaris и т.д. не потому что зеленые потоки плохи, а потому что зеленые потоки и ручное управление памятью пока ни у кого не удалось совместить.
Почему же не удалось? Удалось. Просто через жо.
KP>Еще раз, кто эти остальные? Я обычно использую C++ — тут не осилить потоков зеленых о чем Гор и написал, Python — тут хотя бы обычные дали бы и уже счастье, Go — зеленые потоки есть и на них всё и построено, Elixir — зеленые потоки есть и на них всё вертится.
Дотнет, node.js, quasar в java. KP>UPD. поличтал документацию по Akka и похоже что она тоже фактически на концептах зеленых потоков крутится.
Вопрос не про цвет потоков, а про то, используете ли вы stackful coroutines или stackless.
Если посмотреть с этой точки зрения — вот вам нахрена стек в вашей задаче?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вопрос не про цвет потоков, а про то, используете ли вы stackful coroutines или stackless. S>Если посмотреть с этой точки зрения — вот вам нахрена стек в вашей задаче?
господин большой теоретик?))
можете назвать основной плюс и минус стекфул и стеклесс
и сколько высоконагруженных сетевых приложений на первых и вторых вы уже написали
Здравствуйте, kaa.python, Вы писали:
KP>>>UPD. поличтал документацию по Akka и похоже что она тоже фактически на концептах зеленых потоков крутится.
S>>А можно с этого места поподробнее? Хотя бы ссылку на документацию по Akka, где это описывается?
KP>Я не прав тут, оказывается спутал с неким Quasar.
Здравствуйте, Sinclair, Вы писали:
S>Вопрос не про цвет потоков, а про то, используете ли вы stackful coroutines или stackless.
А чем принципиально green thread от stackful coroutine отличается, особенно если green thread не поддерживаются рантаймом языка и его стандартной библиотекой?
Здравствуйте, so5team, Вы писали: S>А чем принципиально green thread от stackful coroutine отличается, особенно если green thread не поддерживаются рантаймом языка и его стандартной библиотекой?
Ничем. Это два названия примерно одного и того же.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, reversecode, Вы писали: R>господин большой теоретик?)) R>можете назвать основной плюс и минус стекфул и стеклесс
Плюс стекфул — легко реализовать в библиотеке. Можно напилить на более-менее любом языке. Минус — затраты на поддержание стека.
Плюс стеклесс — хорошая масштабируемость. Минус — затраты в разработке платформы; не во всякий язык ложатся хорошо. По-хорошему, нужна поддержка от компилятора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kaa.python, Вы писали:
KP>Я, возможно, что-то упускаю, но если зайти на https://dart.dev/, то первое что бросается в глаза — Дарт для мобильных приложений с UI.
Изначально Dart разрабатывался для клиентских приложений, верно.
KP>Что бы писать на Го мобильное приложение с UI надо быть слабо адекватным человеком
GUI пишут на Golang аж бегом.
KP>Насколько я могу судить, Дарт и Го вообще в разных сегментах и никакой конкуренции между ними нет и быть не может.
В таком ключе сложно рассуждать о мультипарадигменных языках с большим кол-вом фич.
Dart сегодня является универсальным языком, писать на нём серверную/асинхронную/многопоточную часть кода проще, чем на Golang.
Взять даже специфичную фишку Golang — типизированные каналы.
Во-первых, эта функциональность легко покрывается какой-нить либой в других мультипарадигменных языках.
Во-вторых, рядом с полноценным async-await каналы и рядом не стояли, бо последовательности async/await создают типизированный асинхронный "канал" из произвольных типов в каждой точке асинхронного алгоритма. В этом смысле типизированные каналы из Golang — убожество, нищета разума. Это наложение серьёзных ограничений на майл-боксы в исходной модели акторов.
Здравствуйте, Sinclair, Вы писали:
S>Вопрос не про цвет потоков, а про то, используете ли вы stackful coroutines или stackless. S>Если посмотреть с этой точки зрения — вот вам нахрена стек в вашей задаче?
Да мне вообще всё равно что там, пока оно мало памяти ест (это так и для Го и для Эрланга) и не требует код соплями async/await обмазывать. А внутри потоки хоть дрочить в присядку могут, я не возражаю.
Здравствуйте, kaa.python, Вы писали: KP>Да мне вообще всё равно что там, пока оно мало памяти ест (это так и для Го и для Эрланга) и не требует код соплями async/await обмазывать. А внутри потоки хоть дрочить в присядку могут, я не возражаю.
Тогда вас устроят и обычные настоящие потоки. Чем плохо-то?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, reversecode, Вы писали: R>>господин большой теоретик?)) R>>можете назвать основной плюс и минус стекфул и стеклесс S>Плюс стекфул — легко реализовать в библиотеке. Можно напилить на более-менее любом языке. Минус — затраты на поддержание стека. S>Плюс стеклесс — хорошая масштабируемость. Минус — затраты в разработке платформы; не во всякий язык ложатся хорошо. По-хорошему, нужна поддержка от компилятора.
Я так понимаю, что зеленые потоки это файберы https://habr.com/ru/post/185706/ то бишь стекфул ?
Ну в .Net для рекурсивных обхода взяли yield и его же по сути для async await вместо файберов.
Возможно, что бы упростить работу сборщика мусора, что бы еще не держать информацию о стеке файбера
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Тогда вас устроят и обычные настоящие потоки. Чем плохо-то?
Обычные настоящие потоки хороши пока их количество укладывается в тысячу штук (хотя лучше бы в сотню). На трех-четырех десятках тысяч обычных потоков можно уже поиметь неприятные приключения.
Тогда как зеленые потоки (stackful coroutines) позволяют писать код в стиле обычных тредов, но не иметь этих самых проблем при одновременной работе нескольких десятков тысяч зеленых потоков.
ну не совсем то что я ожидал услышать будь то вы практикующий нетворк дев
конкретный вопрос, чем плохи стекфул и стеклесс корутины относительно языка С++
и об этом явно все говорят
как минимум, что полухин, что то другой лектор курса С++ про корутины
и о чем знает любой практикующий нетворк дев который их попробовал
жаль вы пока еще не знаете
ну у вас еще все в переди)
Здравствуйте, Serginio1, Вы писали: S>Я так понимаю, что зеленые потоки это файберы https://habr.com/ru/post/185706/ то бишь стекфул ?
Ага. S>Ну в .Net для рекурсивных обхода взяли yield и его же по сути для async await вместо файберов. S>Возможно, что бы упростить работу сборщика мусора, что бы еще не держать информацию о стеке файбера
В основном — по соображениям эффективности. Я тут уже давал ссылку на статью с подробным исследованием вопроса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, so5team, Вы писали:
S>Обычные настоящие потоки хороши пока их количество укладывается в тысячу штук (хотя лучше бы в сотню). На трех-четырех десятках тысяч обычных потоков можно уже поиметь неприятные приключения. S>Тогда как зеленые потоки (stackful coroutines) позволяют писать код в стиле обычных тредов, но не иметь этих самых проблем при одновременной работе нескольких десятков тысяч зеленых потоков.
Ну, только при этом нужно использовать особенные примитивы синхронизации, и надо всё обмазывать yield в отличие от обычных тредов. А иначе на трёх-четырёх десятках тысяч зелёных потоков всё станет плохо.
В этом смысле async/await масштабируются гораздо лучше.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, reversecode, Вы писали:
R>конкретный вопрос, чем плохи стекфул и стеклесс корутины относительно языка С++
Увы, С++ меня не интересует. Проблемы файберов в нём изучены достаточно хорошо. А что там у них со stackless — я вообще не в курсе, завезли ли уже?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Тогда как зеленые потоки (stackful coroutines) позволяют писать код в стиле обычных тредов, но не иметь этих самых проблем при одновременной работе нескольких десятков тысяч зеленых потоков. S>Ну, только при этом нужно использовать особенные примитивы синхронизации,
Конечно. Только вот если у вас двум независимым и параллельно работающим stackless coroutines потребуется доступ к одним и тем же разделяемым данным, то и им так же нужно будет использовать особенные примитивы синхронизации.
S>и надо всё обмазывать yield в отличие от обычных тредов.
Не обязательно все. Передача управления может выполняться неявно в специальных функциях, предназначенных для использования в зеленых потоках (типа lock, release, send, receive, listen, accept и т.д.)
S>А иначе на трёх-четырёх десятках тысяч зелёных потоков всё станет плохо.
С чего бы это? И почему этого не произойдет на 30-40K одновременно запущенных stackless coroutines?
_>>>>Вот в обратную сторону (то, что автоматизировано в Rust и хрен сделаешь в C++) я могу легко привести пример...
fk0>>> Приведи.
KP>Такое же в C++ очевидно что не сделать настолько же коротко, хотя решения с Cereal или boost.archive будут не так что бы критично длиннее.
Будет критично длиннее. Потому что ты похоже не понял о чём здесь речь или просто не знаешь Rust.
В данном примере речь шла не о наличие какой-то библиотеки сериализации (такого добра в любых языках полно), а о библиотеке Serde, в которой лежат макросы по сути дела реализующие статическую интроспекцию для произвольных типов языка. А уже потом подключаются различные библиотеки сериализации, которых в инфраструктуре Rust'а десятки (и все они умеют использовать данные Serde).
Если говорить про C++, то единственным отдалённо похожим решением является BOOST_FUSION_ADAPT_STRUCT. Надеюсь тебе не надо рассказывать про всю уродливость этого решения? Ну и естественно и речи нет о том, чтобы все библиотеки сериализации C++ умели в BOOST_FUSION_ADAPT_STRUCT и считали это стандартом. Что впрочем логично как раз из-за уродливости.
KP>В то же время исходя из моего опыта этот пример крутой фичи с серриализаций довольно бесмысленный. Ну можешь ты что-то запаковать и распаковать в Rust, а дальше что?
Тебе реально надо объяснять в чём разница когда мы пишем код руками или когда его пишет за нас компилятор?
Особенно забавен этот твой вопрос на фоне восторженного упоминания Protobuf, который делает такую же (правда только в один убогий формат) автоматизацию, но сторонними средствами и с помощью отдельного "языка программирования".
KP>Это можно как-то так же бесшовно распаковать в Python или в C++? Потому как если нет, то фича эта прикольная, но в проде окажется Protobuf
Protobuf у нас на проде точно никогда не окажется в силу его крайне низкой эффективности (см. например табличку здесь https://blog.logrocket.com/rust-serialization-whats-ready-for-production-today/). Благо сейчас нет никаких проблем писать код со всех сторон (и на сервере и на клиенте, в том числе в браузере) на Rust.
