Анатомия асинхронных движков - Антон Полухин

Тезисы: В последние годы практически во всех языках программирования набирают популярность асинхронные движки с корутинами. Давайте посмотрим, как эти движки устроены и что в них такого хорошего для I/O- bound приложений! Посмотрим, как люди жили до современных корутин, рассмотрим базовые компоненты асинхронного движка, и окунёмся в дивный мир движковых оптимизаций и хитростей:
использование стека как «кучи»;
мьютексы, которые не блокируют потоки;
таймеры и поколения;
отмены.

[@sovrinfo]

Спасибо за видео.Коммент в поддержку!

[@user-bl4mm5pr9g]

Спасибо!

[@Alexander-mj3jk]

А что под капотом у стакфулл короутин? Каким образом получается сохранить локальные переменные в процедуре?

[@usmanbaybikov9462]

Все видео было ощущение , что лектор говорить про шедуллер Go)

[@SharplEr]

Ну это одна и так же идея.

[@rugleb]

Создание потока на питоне - не проблема. Проблема в том, что потоки не будут работать параллельно.

[@jekapsk]

Смотря какой движок питона использовать) есть реализации без GIL, но тогда придется писать tread-safe код)

[@rugleb]

@@jekapsk по умолчанию все понимают о каком движке речь) А так конечно, можно пытаться и мертвого воскрешать

[@alexandersmirnov4274]

объясните стекфул vs стеклесс корутины?

[@cdriper]

стекфул ничем не отличается от классического кода со стеком стеклесс код хранит все "локальные" переменные не на стеке, а в специально отведенном регионе памяти (который обычно располагают в куче) главное преимущество такого подхода -- расход памяти ты должен выделить ровно столько памяти, сколько реально надо для работы конкретной корутины в случае классического стека ты всегда выделяешь на глазок и делаешь это с запасом, что приводит к перерасходу памяти недостатоки стеклесс -- необходимость отмечать все корутины специальным образом и невозможность их использования как обычных методов плюс современные компиляторы, увы, не могут предсказать размер региона под переменные на этапе компиляции и память нужно выделять каким-то образом в рантайме

[@vlad071096]

Где-нибудь можно найти информацию, почему переключение контекста (уровня ОС) такое дорогое? Вот на 5:53, например, написано total costs, including cache invalidation? Какие кеши инвалидируются? В современных процессорах physically-tagged кеши (VIPT или PIPT), их не надо инвалидировать при переключении контекста. TLB для переключения на тред того же процесса инвалидировать не надо, и вообще современные TLB поддерживают теги адресных пространств. У меня ощущение, что для человека "со стороны", который не разрабатывает процессоры или операционные системы, во всем Интернете невозможно найти нормальный ответ на вопрос "зачем нужен user-space scheduling" (корутины, файберы, горутины, или что там в вашей среде есть). В худшем случае будет бредятина про то, что стеки ОС-тредов занимают слишком много памяти (ну да, ведь 2^64 байт - это так мало для масштабируемости), а в лучшем - про инвалидацию кешей.

[@cdriper]

я думаю, что главная здесь проблема это race condition или ты сам управляешь переключением в "безопасные" и понятные моменты времени или это делает операционная система (например, посредине инкремента целого числа, который выполняется в две машинные инструкции)

[@olsuhvlad]

20:38 - Rust это все отслеживает :)

[@olsuhvlad]

50:10 - тоже отсутствует в Rust'e :)

[@cdriper]

не самый хороший доклад с точки зрения формулирования мыслей и использования терминологии для тех, кто плохо разбирается в теме, может скорее сбить с толка, чем что-то прояснить корутины (особенно stackful) это нифига не колбэки это потоки выполнения, похожие на threads, а корутинный движок это их шедулер