Анатомия асинхронных движков - Антон Полухин
ฝัง
- เผยแพร่เมื่อ 28 มิ.ย. 2022
- Тезисы: В последние годы практически во всех языках программирования набирают популярность асинхронные движки с корутинами. Давайте посмотрим, как эти движки устроены и что в них такого хорошего для I/O- bound приложений! Посмотрим, как люди жили до современных корутин, рассмотрим базовые компоненты асинхронного движка, и окунёмся в дивный мир движковых оптимизаций и хитростей:
использование стека как «кучи»;
мьютексы, которые не блокируют потоки;
таймеры и поколения;
отмены. - วิทยาศาสตร์และเทคโนโลยี
Спасибо за видео.Коммент в поддержку!
Спасибо!
А что под капотом у стакфулл короутин? Каким образом получается сохранить локальные переменные в процедуре?
Все видео было ощущение , что лектор говорить про шедуллер Go)
Ну это одна и так же идея.
Создание потока на питоне - не проблема. Проблема в том, что потоки не будут работать параллельно.
Смотря какой движок питона использовать) есть реализации без GIL, но тогда придется писать tread-safe код)
@@jekapsk по умолчанию все понимают о каком движке речь)
А так конечно, можно пытаться и мертвого воскрешать
объясните стекфул vs стеклесс корутины?
стекфул ничем не отличается от классического кода со стеком
стеклесс код хранит все "локальные" переменные не на стеке, а в специально отведенном регионе памяти (который обычно располагают в куче)
главное преимущество такого подхода -- расход памяти
ты должен выделить ровно столько памяти, сколько реально надо для работы конкретной корутины
в случае классического стека ты всегда выделяешь на глазок и делаешь это с запасом, что приводит к перерасходу памяти
недостатоки стеклесс -- необходимость отмечать все корутины специальным образом и невозможность их использования как обычных методов
плюс современные компиляторы, увы, не могут предсказать размер региона под переменные на этапе компиляции и память нужно выделять каким-то образом в рантайме
Где-нибудь можно найти информацию, почему переключение контекста (уровня ОС) такое дорогое? Вот на 5:53, например, написано total costs, including cache invalidation? Какие кеши инвалидируются? В современных процессорах physically-tagged кеши (VIPT или PIPT), их не надо инвалидировать при переключении контекста. TLB для переключения на тред того же процесса инвалидировать не надо, и вообще современные TLB поддерживают теги адресных пространств. У меня ощущение, что для человека "со стороны", который не разрабатывает процессоры или операционные системы, во всем Интернете невозможно найти нормальный ответ на вопрос "зачем нужен user-space scheduling" (корутины, файберы, горутины, или что там в вашей среде есть). В худшем случае будет бредятина про то, что стеки ОС-тредов занимают слишком много памяти (ну да, ведь 2^64 байт - это так мало для масштабируемости), а в лучшем - про инвалидацию кешей.
я думаю, что главная здесь проблема это race condition
или ты сам управляешь переключением в "безопасные" и понятные моменты времени или это делает операционная система (например, посредине инкремента целого числа, который выполняется в две машинные инструкции)
20:38 - Rust это все отслеживает :)
50:10 - тоже отсутствует в Rust'e :)
не самый хороший доклад с точки зрения формулирования мыслей и использования терминологии
для тех, кто плохо разбирается в теме, может скорее сбить с толка, чем что-то прояснить
корутины (особенно stackful) это нифига не колбэки
это потоки выполнения, похожие на threads, а корутинный движок это их шедулер