О структуре параллельных вычислений или доводы против оператора «Go»

Автор оригинала: Nathaniel J. Smith
  • Перевод


Каждый язык, поддерживающий параллельные (конкурентные, асинхронные) вычисления, нуждается в способе запуска кода параллельно. Вот примеры из разных API:


go myfunc();                                // Golang

pthread_create(&thread_id, NULL, &myfunc);  /* C with POSIX threads */

spawn(modulename, myfuncname, [])           % Erlang

threading.Thread(target=myfunc).start()     # Python with threads

asyncio.create_task(myfunc())               # Python with asyncio

Есть много вариантов нотации и терминологии, но одна семантика — запустить myfunc параллельно основной программе и продолжить родительский поток выполнения (англ. "Control Flow")


Другой вариант — Коллбэки:


QObject::connect(&emitter, SIGNAL(event()),        // C++ with Qt
                 &receiver, SLOT(myfunc()))

g_signal_connect(emitter, "event", myfunc, NULL)   /* C with GObject */

document.getElementById("myid").onclick = myfunc;  // Javascript

promise.then(myfunc, errorhandler)                 // Javascript with Promises

deferred.addCallback(myfunc)                       # Python with Twisted

future.add_done_callback(myfunc)                   # Python with asyncio

И снова нотация меняется, но все примеры делают так, что, начиная с текущего момента, если и когда случится определенное событие, тогда запустится myfunc. Как только callback установлен, управление возвращается и вызывающая функция продолжает работу. (Иногда коллбэки обернуты в удобные комбинирующие функции или протоколы в стиле Twisted, но базовая идея неизменна.)


И… Это все. Возьмите любой популярный язык общего назначения с поддержкой параллельности и вы вероятно обнаружите, что он попадает в одну из этих парадигм (иногда обе, как asyncio).


Но не моя новая странная библиотека Trio. Она не использует эти подходы. Вместо них, если мы хотим запустить myfunc и anotherfunc параллельно, мы пишем примерно так:


async with trio.open_nursery() as nursery:
    nursery.start_soon(myfunc)
    nursery.start_soon(anotherfunc)

nursery — ясли, питомник

Впервые столкнувшись с конструкцией "питомник", люди теряются. Зачем тут менеджер контекста (with-блок)? Что это за питомник, и зачем он нужен для запуска задачи? Потом люди понимают, что питомник мешает использовать привычные в других фреймворках подходы и злятся. Всё кажется причудливым, специфичным и слишком высокоуровневым, чтобы быть базовым примитивом. Все это понятные реакции! Но потерпите немного.


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


Звучит слишком смело? Но подобное уже случалось: некогда goto широко использовался для управления поведением программы. Теперь же это повод посмеяться:



Несколько языков все ещё имеют так называемый goto, но его возможности ограничены намного сильнее, чем у оригинального goto. А в большинстве языков его вообще нет. Что же с ним случилось? Эта история удивительно актуальна, хотя и незнакома большинству из-за своей древности. Давайте напомним себе, чем был goto, и потом посмотрим, чем это может помочь в асинхронном программировании.


Оглавление


  • Что такое goto?
  • Что такое go?
  • Что случилось с goto?
    • goto разрушает абстракции
    • Дивный новый мир без goto
    • Больше никаких goto
  • О вреде выражений типа “Go”
    • go-выражения ломают абстракции.
    • go-выражения ломают автоочистку открытых ресурсов.
    • go-выражения ломают обработку ошибок.
    • Больше никаких go
  • Питомник как структурная замена go
    • Питомник сохраняет абстракцию функций.
    • Питомник поддерживают динамическое добавление задач.
    • Из питомника всё ещё можно выйти.
    • Вы можете определить новые типы, которые крякают как питомник.
    • Нет, правда, питомники всегда ждут окончания всех задач внутри.
    • Работает автоматическая очистка ресурсов.
    • Работает поднятие ошибок.
    • Дивный новый мир без go
  • Питомники на практике
  • Выводы
  • Комментарии
  • Благодарности
  • Сноски
  • Об авторе
  • Продолжение

Что такое goto?


Первые компьютеры программировались с помощью ассемблера, или даже более примитивно. Это не очень удобно. Так что в 1950-х люди типа Джона Бэкуса из IBM и Грейс Хоппер из Remington Rand начали разрабатывать языки типа ФОРТРАН и FLOW-MATIC (более известный его прямым потомком КОБОЛ ).


FLOW-MATIC был очень абициозным в свое время. Можно думать о нем как о пра-пра-пра-прадедушке Питона — это был первый язык, разработанный в первую очередь для людей, и во вторую для компьютеров. Выглядел он вот так:



Заметьте, что в отличие от современных языков, тут нет условных блоков if, циклов или вызовов функций — по факту тут нет блоков или отступов вообще. Это просто последовательный список выражений. Не потому, что данная программа слишком коротка, чтобы понадобились операторы управления (кроме JUMP TO) — просто такой синтаксис ещё не был изобретен!



Вместо этого, FLOW-MATIC имел две возможности управлять потоком выполнения. Обычно поток был последовательным — начать сверху и двигаться вниз, одно выражение за раз. Но если выполнить специальное выражение JUMP TO, оно могло перенести управление куда-то ещё. Например, выражение (13) перепрыгивает к выражению (2):



Так же, как с примитивами параллельности из начала статьи, тогда не было согласия, как назвать эту "сделай прыжок в одну сторону" операцию. В листинге это JUMP TO, но исторически прижилось goto (как "иди туда"), который я тут использую.


Вот полный набор прыжков goto в этой маленькой программе:



Это кажется запутанным не только вам! Такой стиль программирования, основанный на прыжках, FLOW-MATIC унаследовал прямо из ассемблера. Он мощный, хорошо приближен к тому, как на самом деле работает компьютерное "железо", но с ним очень трудно работать напрямую. Этот клубок стрелок — причина изобретения термина "спагетти-код".


Но почему goto вызывает такую проблему? Почему некоторые операторы управления хороши, а другие нет? Как выбрать хорошие? В то время это было совершенно непонятно, а если вы не понимаете проблему, её трудно решить.


Что такое go?


Давайте отвлечемся от нашей истории. Все знают, что goto был плохим, но какое отношение это имеет к асинхронности? Посмотрите на известное выражение go из Golang, которое используется чтобы породить новую "горутину" (легковесный поток):


// Golang
go myfunc();

Можно ли нарисовать диаграмму ее потока выполнения? Она немного отличается от диаграммы выше, потому что тут поток разделяется. Нарисуем её вот так:



Цвета тут призваны показать, что оба пути выбраны. С точки зрения родительской горутины (зеленая линия) — поток управления выполняется последовательно: он начинается сверху и потом немедленно идет вниз. Тем временем, с точки зрения функции-потомка (сиреневая линия) — поток приходит сверху и потом прыгает в тело myfunc. В отличие от обычного вызова функции, тут происходит прыжок в одну сторону — запуская myfunc мы переключаемся в совершенно новый стек и среда выполнения сразу забывает, откуда мы пришли.


видимо имеется в виду стек вызовов

Но это применимо не только к Golang. Это диаграмма верна для всех примитивов (управления), перечисленных в начале статьи:


  • Библиотеки управления потоками (threading libraries) обычно возвращают некоторый контрольный объект, который позволит присоединиться к потоку позже — но это независимая операция, о которой сам язык не знает ничего. Примитив для создания нового потока имеет диаграмму, показанную выше.
  • Регистрация коллбэка семантически эквивалентна созданию фонового потока (хотя очевидно, что реализация отличается), который:
    а) блокируется, пока не случится какое-либо событие, и потом
    б) запускает коллбэк-функцию
    Так что, в терминах высокоуровневых операторов управления, регистрация коллбэка — выражение, идентичное go.
  • С Futures и Promises то же самое — когда вы запускаете функцию и она возвращает Promise, это значит что она запланировала работу в фоне, и возвращает контрольный объект, чтобы достать результат позже (если вы захотите). С точки зрения семантики управления, это то же самое, что породить поток. После этого вы передаете промису коллбэк и далее как в предыдущем пункте.

Этот же самый паттерн показывает себя во множестве форм — ключевое сходство в том, что во всех этих случаях поток управления разделяется — выполняется прыжок в новый поток, но родительский возвращается к тому, кто его вызвал. Зная, на что смотреть, вы увидите это повсюду! Это интересная игра (по крайней мере для некоторых типов людей)!


И всё же меня раздражает, что для этой категории операторов управления нет стандартного имени. Я использую выражение "go" чтобы называть их, так же как "goto" стало обобщающим термином для всех похожих на goto выражений. Почему go? Одна причина в том, что Golang дает нам очень чистый пример такого синтаксиса. А другая вот:



Заметили схожесть? Все верно — go это одна из форм goto.


Асинхронные программы печально известны трудностью написания и анализа. Так же как и программы, основанные на goto. Проблемы, вызванные goto, в современных языках в основном решены. Если мы изучим, как починили goto, поможет ли это создать более удобные асинхронные API? Давайте выясним!


Что случилось с goto?


Так что же не так с goto, что вызывает так много проблем? В поздних 60-х Эдсгер Вибе Дейкстра написал пару известных теперь работ, которые помогли понять это гораздо яснее: Доводы против оператора goto и Заметки по структурному программированию.


goto разрушает абстракции


В этих работах Дейкстра волновался о том, как нам писать нетривиальные программы и обеспечивать их корректность. Там есть множество интересных моментов. Например, вы наверное слышали эту фразу:


Тестирование программ может показать наличие ошибок, но никогда не их отсутствие.

Да, это из Заметок по структурному программированию. Но его главной заботой была абстракция. Он хотел писать программы, слишком большие, чтобы держать их в голове целиком. Чтобы делать это, вы должны относиться к частям программы, как к черным ящикам — как например, вы видите эту программу на Python:


print("Hello World!")

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


К этому моменту был изобретен блочный синтаксис и языки типа ALGOL аккумулировали ~5 разных типов операторов управления: они все еще имели последовательный поток выполнения и goto:



А также приобрели условия, циклы и вызовы функций:



Вы можете реализовать эти высокоуровневые конструкции используя goto, и это то, как ранее люди думали о них: как об удобном сокращении. Но Дейкстра указал на большую разницу между goto и остальными операторами управления. Для всего, кроме goto, поток выполнения


  • приходит сверху => [чтото случается] => поток выходит снизу

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


print("Hello World!")

мне не нужно читать исходники print и всех его зависимостей, чтобы понять, куда пойдет поток выполнения. Может быть внутри print есть цикл, а в нем условие, в котором есть вызов другой функции… это все не важно — я знаю, что поток выполнения войдет в print, функция выполнит свою работу, и в итоге поток выполнения вернется к коду, который я читаю.


Но если у вас есть язык с goto — язык, где функции и все остальное построено на основе goto, и goto может прыгнуть куда угодно, в любое время — тогда эти структуры совсем не являются черными ящиками! Если у вас есть функция с циклом, внутри которого условие, а внутри него есть goto… тогда этот goto может передать выполнение куда угодно. Возможно, управление внезапно полностью вернется из другой функции, которую вы еще даже не вызвали! Вы не знаете!


И это ломает абстракцию — любая функция может иметь потенциальный goto внутри, и единственный способ узнать, так ли это — держать весь исходный код вашей системы в голове. Как только в языке есть goto, вы не можете предсказать поток выполнения. Вот почему goto ведет к спагетти-коду.


И как только Дейкстра понял проблему — он смог решить её. Вот его революционное предположение — мы должны думать об условиях/циклах/вызовах функций не как о сокращениях для goto, но как о фундаментальных примитивах со своими правами — и мы должны полностью удалить goto из наших языков.


Из 2018 года это выглядит вполне очевидным. Но как реагируют программисты, когда вы пытаетесь забрать их небезопасные игрушки? В 1969-м, предложение Дейкстры казалось невероятно сомнительным. Дональд Кнут защищал goto. Люди, которые стали экспертами по написанию кода с goto, вполне обоснованно негодовали против необходимости заново учиться тому, как выражать свои идеи в новых, более ограничивающих выражениях. И конечно, потребовалось создать совершенно новые языки.


В итоге современные языки немного менее строги, чем оригинальная формулировка Дейкстры.



Слева: традиционный goto. Справа: Одомашненный goto, как в C, C#, Golang, и т.д. Неспособность пересечь границы функции значит, что он все еще может пописать на ваши ботинки, но вряд ли сможет вас разорвать.

Они позволяют вам перепрыгнуть уровни вложенности структурных операторов управления, используя операторы break, continue, или return. Но на базовом уровне, они все построены вокруг идеи Дейкстры и могут нарушать последовательный поток выполнения строго ограниченным образом. В частности, функции — фундаментальный инструмент для оборачивания потока выполнения в черный ящик — являются неразрушимыми. Вы не можете выполнить команду break из одной функции в другую и return не может вернуть вас дальше текущей функции. Никакие манипуляции с потоком выполнения внутри функции не затронут другие функции.


А языки, сохранившие оператор goto (С, С#, Golang, ...), сильно его ограничили. Как минимум, они не позволяют вам прыгать из тела одной функции в другую. Если вы не используете Assembler [2], классический, неограниченный goto ушёл в прошлое. Дейкстра выиграл.


Дивный новый мир без goto


Кое-что интересное случилось с исчезновением goto — создатели языков смогли начать добавлять новые возможности, опирающиеся на структурированный поток выполнения.


Например, в Питоне есть классный синтаксис для автоматической очистки ресурсов — менеджер контекста. Вы можете написать:


# Python
with open("my-file") as file_handle:
    some code

и это гарантирует, что файл будет открыт во время выполнения some code но после — немедленно закрыт. Большинство современных языков имеют эквиваленты (RAII, using, try-with-resource, defer, ...). И все они предполагают, что поток управления идет по порядку. А что случится, если мы запрыгнем в блок with используя goto? Файл открыт или нет? А если мы выпрыгнем оттуда вместо того, чтобы выйти как обычно?


после того, как код внутри блока завершен, with запускает метод __exit__() который и закрывает открытые ресурсы, такие как файлы и соединения.

Закроется ли файл? В языке с goto менеджеры контекста просто не работают чётким образом.


Та же проблема с обработкой ошибок — когда что-то идет не так, что должен сделать код? Часто — послать описание ошибки выше по стеку (вызовов) к вызывающему коду и позволить ему решать, что делать. Современные языки имеют конструкции специально для этого, такие как Исключения (Exceptions) или другие формы автоматического поднятия ошибок. Но эта помощь доступна только если в языке есть стек вызовов и надежная концепция "вызова". Вспомните спагетти потока выполнения в примере на FLOW-MATIC и представьте исключение, выброшенное в середине. Куда оно вообще может прийти?


Больше никаких goto


Итак, традиционный goto — который игнорирует границы функций — плох не только потому, что его трудно использовать корректно. Если бы только это, goto мог бы и остаться — множество плохих языковых конструкций остались.


Но даже сама возможность goto в языке делает всё сложнее. Сторонние библиотеки не могут считаться чёрным ящиком — не зная исходники, не разобраться, какие функции обычные, а какие непредсказуемо управляют потоком выполнения. Это серьезное препятствие для предсказания локального поведения кода. Также теряются мощные возможности, такие как менеджеры контекста и автоматическое всплытие ошибок. Лучше удалить goto совсем, в пользу операторов управления, которые поддерживают правило "черного ящика".


О вреде выражений типа "Go"


Итак, мы рассмотрели историю goto. Но применима ли она к оператору go? Ну… в общем, полностью! Аналогия получилась шокирующе точной.


go-выражения ломают абстракции.


Помните, как мы сказали, что если язык позволяет goto, то любая функция может скрывать в себе goto? В большинстве асинхронных фреймворков, go-выражения приводят к той же проблеме — любая функция может (а может и нет) запустить задачу в фоне. Выглядит, как будто функция вернула управление, но работает ли она все еще в фоне? И нет способа это узнать, не прочитав исходники функции и всего, что она вызывает. И когда она завершится? Трудно сказать. Если у вас есть go и его аналоги, тогда функции больше не чёрные ящики, которые уважают поток выполнения. В моей первой статье про асинхронные API, я назвал это "нарушением причинности", и нашел, что это первопричина многих распространённых, реальных проблем в программах, использующих asyncio и Twisted, таких как проблемы контроля потока, проблемы правильного выключения и т.д.


имеется в виду контроль потока данных, входящих и выходящих из программы. Например, в программу приходят данные со скоростью 3МБ/с, а уходят со скоростью 1МБ/с, и соответственно программа потребляет все больше и больше памяти, см. другую статью автора

go-выражения ломают автоочистку открытых ресурсов.


Давайте снова взглянем на пример выражения with:


# Python
with open("my-file") as file_handle:
    some code

Ранее мы сказали, что нам "гарантированно", что файл будет открыт, пока some code работает, и закрыт после. Но что если some code запускает фоновую задачу? Тогда наша гарантия потеряна: операции, которые выглядят, как будто они внутри with, на самом деле могут работать после завершения блока with, и вызвать ошибку, потому что файл закрылся, пока он всё ещё им нужен. И снова, вы не можете судить об этом локально; чтобы исключить подобное, вам придется прочитать все исходники всех функций, вызванных внутри some code.


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


Переводчик статьи сам столкнулся с такой задачей, используя в Python модуль threading — пришлось создать глобальную для моего модуля структуру, в которой хранились объекты управления всеми фоновыми задачами, и при завершении программы закрывать их все в цикле — значительно больше кода, чем удобная конструкция with

Это выполнимо, если мы используем библиотеку, предоставляющую оповещения о завершении задачи, но таких удручающе мало (обычно библиотеки не возвращают объект управления фоновой задачей). Но и в этом случае, неструктурированный поток выполнения не позволяет языку помочь нам. Приходится вручную управлять закрытием ресурсов, как в старые недобрые времена.


go-выражения ломают обработку ошибок.


Как мы обсудили выше, современные языки предоставляют мощные инструменты, такие как Исключения (exceptions), для гарантий обнаружения ошибок и передачи их в нужное место. Но эти инструменты полагаются на надежную концепцию "вызывающего кода". Как только вы запускаете новую задачу или регистрируете коллбэк, эта концепция сломана. В результате, все известные мне популярные асинхронные фреймворки, просто сдаются. Если в фоновой задаче случилась ошибка, и вы не обработали ее на месте, тогда среда выполнения… выводит ошибку в консоль и надеется, что она была не слишком важна. Если вам повезло, она напечатает что-нибудь в терминал. (Единственный софт из тех, что я использовал, который считает "напечатай что-нибудь и работай дальше" хорошей стратегией обработки ошибок — это старые безобразные библиотеки Фортрана; но асинхронные библиотеки делают так же.) Даже Rust — язык, известный, как самый помешанный на корректности многопоточного программирования из-за своей высокой инженерной культуры — виновен в этом грехе. Если фоновый поток выполнения (thread) сломался, Rust отбрасывает ошибку и надеется на лучшее.


Конечно, вы можете обрабатывать ошибки правильно в таких системах, вызывая join для каждого потока или создавая собственный механизм поднятия ошибок, такой как errbacks в Twisted или Promise.catch в Javascript. Но теперь вы воссоздаёте локальную, хрупкую реализацию возможностей, которые ваш язык уже имеет. И теряете такие полезные вещи, как Traceback и отладку. И стоит всего лишь забыть вызов Promise.catch и серьёзные ошибки могут быть не замечены.


Даже ухитрившись решить все эти проблемы, теперь мы имеем две системы обработки ошибок.


Больше никаких go


Также, как goto был очевидным примитивом для первых практических высокоуровневых языков, go-выражения стали очевидным примитивом для первых практических конкурентных фреймворков — они совпадают с тем, как работают нижележащие планировщики, и достаточно мощны, чтобы реализовать любые паттерны конкурентных потоков. Но также, как и goto, они ломают абстракции потока выполнения, поэтому даже возможность наличия go в языке делает всё остальное трудным для использования.


Хорошие новости в том, что Дейкстра уже показал нам, как решать все эти проблемы! Нам нужно:


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

И это то, что сделал Trio.


Питомник как структурная замена go


Корневая идея такова: каждый раз, когда поток выполнения разделяется на несколько параллельных путей, мы должны убедится, что они соединятся снова. Например, если мы хотим делать три вещи одновременно, наш поток выполнения должен выглядеть примерно так:



Заметьте, что только одна стрелка входит сверху, и только одна выходит снизу, так что блок соответствует "правилу чёрного ящика" Дейкстры.


Как же превратить эту зарисовку в конкретную конструкцию языка? Существует несколько подходящих под "чёрный ящик" конструкций, но


а) моё предложение немного отличается от тех, которые мне известны, и имеет преимущества (особенно в свете желания создать отдельный примитив), и
б) литература по параллельным вычислениям огромна и сложна, и попытка разобраться со всеми вариантами и компромиссами является темой для отдельной статьи.


Здесь я фокусируюсь на объяснении моего решения. Я не заявляю, что типа изобрел идею параллельных вычислений или чего-то подобного. Идея черпает вдохновение из многих источников, я стою на плечах гигантов и т.д. [3]


Вот как мы это сделаем: первое, мы декларируем, что родительская задача не может запускать никаких потомков, пока вначале не создаст "питомник", где они будут жить. В Trio мы делаем это, используя питоновский синтаксис async with:



Открытие питомника автоматически создаёт представляющий его объект, и синтаксис as nursery назначает этот объект переменной nursery. Теперь мы используем метод питомника nursery.start_soon(), чтобы запускать фоновые (параллельные) задачи: в нашем случае это функции myfunc и anotherfunc. Концептуально эти задачи выполняются внутри питомника. Часто удобно думать о коде, написанном внутри питомника, как о начальной (родительской) задаче, которая автоматически стартует, когда питомник создан.



Критично важно, что питомник не закроется, пока все задачи внутри не будут выполнены — если родительская задача достигнет конца блока перед тем, как все потомки закончили, тогда она притормозит там и подождет их. Питомник автоматически расширяется, чтобы вместить потомков.


вероятно, имеются в виду временные рамки.

Вот диаграмма потока выполнения и она совпадает с базовой моделью из начала этого раздела:



Такой дизайн имеет много последствий, не все из которых очевидны. Вот некоторые из них:


Питомник сохраняет абстракцию функций.


Корневая проблема go-выражений — когда вы вызываете функцию, неизвестно, не запустит ли она фоновую задачу, которая будет выполняться после её завершения. С питомниками вам не надо об этом волноваться — любая функция может открыть питомник и запустить множество параллельных задач, но функция не может вернуть управление, пока они все не завершатся. Когда поток выполнения возвращается из функции, вы знаете, что она действительно закончена.


Питомник поддерживают динамическое добавление задач.


Вот более простой примитив, который также удовлетворяет приведённой выше диаграмме потока выполнения. Он берет список задач и запускает их все параллельно:


run_concurrently([myfunc, anotherfunc])

async.gather в Python, Promise.all в Javascript, и т.п.

Но проблема в том, что вы должны знать заранее весь список задач, которые вы собираетесь запускать, что возможно не всегда. Например, серверные программы обычно имеют цикл с accept, который берет входящие соединения и запускает новую задачу для обработки каждого из них.
Вот минимальный accept цикл в Trio:


async with trio.open_nursery() as nursery:
    while True:
        incoming_connection = await server_socket.accept()
        nursery.start_soon(connection_handler, incoming_connection)

С питомниками это элементарно, но сделать это, используя run_concurrently будет намного более неудобно. Если вы захотите, будет легко создать run_concurrently на основе питомников — но это не нужно, так как в простых случаях, где пригодится run_concurrently, синтаксис питомников настолько же прост.


Из питомника всё ещё можно выйти.


Из питомника есть аварийный выход. Что если вам нужно написать функцию, которая порождает фоновую задачу, и эта задача должна пережить родителя? Легко: передайте объект питомника в эту функцию. Нет правила, что только блок async with open_nursery() может запускать nursery.start_soon(), — пока питомник открыт [4], любой, кто получил ссылку на питомник, получает возможность запускать в нем задачи. Вы можете передать ссылку как аргумент функции, передать её через очередь, что угодно.


На практике это означает, что вы можете писать функции, которые "ломают правила", но внутри определенных границ:


  • объект питомника должен передаваться явно, и вы можете легко понять, какие функции нарушают нормальный поток выполнения, просто посмотрев на их аргументы, так что возможно предсказать, куда пойдет поток выполнения.
  • запущенные функцией потомки всё так же связаны с питомником, который ей передали.
  • вызывающий код может запускать задачи только в питомниках, к которым имеет доступ.

Так что питомники все еще очень отличаются от традиционной модели, где любой код может в любой момент породить фоновую задачу с неограниченным временем жизни.


Эта возможность позволяет доказать, что питомники обладают выразительностью, эквилалентной go-выражениям, но я оставлю это для другой статьи.


Вы можете определить новые типы, которые крякают как питомник.


Стандартная семантика питомника даёт прочную основу, но иногда вы захотите что-либо другое. Может быть из зависти к Эрлангу и его супервайзерам вы хотите создать класс такой как питомник, но который обрабатывает исключения, перезапуская фоновые задачи. Это безусловно возможно и будет выглядеть как обычный питомник для ваших пользователей:


async with my_supervisor_library.open_supervisor() as nursery_alike:
    nursery_alike.start_soon(...)

Если ваша функция принимает питомник в аргументах, можете передать ей ваш тип вместо питомника, для контроля стратегии обработки ошибок. Довольно удобно.


Правда Trio следует не таким условным соглашениям, как asyncio и некоторые другие библиотеки: start_soon() должен принимать функцию, а не корутину или Future (вы можете вызвать функцию множество раз, но нет способа перезапустить корутину или Future). Я думаю, что такое соглашение лучше по множеству причин (особенно потому, что у Trio вообще нет Future!), но все таки стоило об этом упомянуть.


Нет, правда, питомники всегда ждут окончания всех задач внутри.


Также важно поговорить о взаимодействии отмены задач и присоединения к задачам, так как тут есть тонкости, которые могут — если неправильно ими управлять — сломать постоянство питомника.


В Trio, код может получить запрос на отмену выполнения в любое время. После того как отмена запрошена, в следующий раз, когда код проходит "контрольную точку" (детали), вызывается исключение Cancelled. Это значит, что есть задержка между запросом отмены и тем, когда она действительно случится — может пройти какое-то время, прежде чем задача дойдет до "контрольной точки", и после этого исключение должно отмотать стек вызовов, запустить очистку и т.д. Когда такое случается, питомник всегда ждет, пока очистка полностью завершится. Мы никогда не убиваем задачу, не дав ей шанс запустить обработчики очистки, и мы никогда не оставляем задачу работать без присмотра снаружи питомника, даже если она в процессе отмены.


Работает автоматическая очистка ресурсов.


Так как питомники следуют "правилу чёрного ящика", блоки with снова работают. Например, закрытие файла в конце блока with не сломает внезапно фоновую задачу, которая всё ещё использует этот файл.


Работает поднятие ошибок.


Как отмечено выше, в большинстве асинхронных фреймворков, необработанные ошибки из фоновых задач просто отбрасываются. С ними буквально ничего не поделать.


В Trio, все фоновые задачи живут питомнике, а родительская задача обязана ждать окончания задач в питомнике… поэтому мы можем кое-что сделать с необработанными исключениями. Если фоновая задача завершается с исключением, мы можем перебросить исключение в родительскую. Идея в том, что питомник — это как бы примитив "параллельного вызова" — можно думать о нашем примере, как об одновременном вызове myfunc и anotherfunc, так что наш стек вызовов становится деревом. А исключения поднимаются по дереву вызовов в сторону корня, так же, как они поднимаются по обычному стеку вызовов.


Врочем, тут есть одна тонкость: если мы перезапустим (re-raise) исключение в родительской задаче, оно поднимется ещё выше. В общем это значит, что родительская задача выйдет из питомника


под "родительской задачей" тут, по видимому, имеется в виду код внутри питомника, который и запускает фоновые задачи, а не код, который создал питомник.

Но мы же сказали, что родительская задача не может покинуть питомник, пока там ещё остались работающие потомки. Что же нам делать?


Ответ — когда в потомке (фоновой задаче) случается необработанное исключение, Трио немедленно отменяет все другие задачи в этом питомнике и ждет их завершения перед перезапуском исключения. Идея в том, что исключения заставляют отмотать стек вызовов, и если мы хотим отмотать назад одну из веток нашего дерева вызовов, мы должны отмотать и другие ветки, путем их отмены.


Это значит впрочем, что если вы хотите реализовать питомники в своем языке, вам может понадобиться какая-либо интеграция между кодом питомников и вашей системой остановки задач (task cancellation). Это может быть сложным в языках типа C# или Golang, где остановка задач обычно управляется через ручную передачу объектов и специальные соглашения или даже хуже — язык вообще не имеет общего механизма отмены.


Дивный новый мир без go


Устранение goto позволило прежним создателям языков создать более сильные допущения о структуре программ, что разрешило новые возможности типа менеджеров контекста with и исключений; устранение go-выражений имеет схожий эффект. Например:


  • система остановки задач в Трио надежней и проще, чем у соперников, потому что предполагается, что задачи вложены в правильную древовидную структуру. (полная дискуссия: Таймауты и завершение задач по-человечески)
  • Трио — единственная Python библиотека для параллельных вычислений, где ctrl-C работает ожидаемым образом (детали). Это было бы невозможно, если бы питомники не предоставили надежный механизм поднятия исключений.

Питомники на практике


Итак, это была теория. А как это работает на практике?


Ну… это эмпирический вопрос: вам стоит попробовать и узнать! Серьезно, мы просто не узнаем наверняка, пока множество людей не попробует. Сейчас я вполне уверен что основа хороша, но может оказаться что нам нужно будет добавить некоторые правки, также, как ранние теоретики структурного программирования в итоге оставили break и continue.


Если у вас большой опыт в асинхронном программировании, вы можете найти Трио немного шероховатым. Вам понадобится выучить новые способы для привычных вещей — так же, как программистам 1970х было трудно выучить, как писать код без goto.


Но в том то и дело. Как написал Кнут (Knuth, 1974, стр.275):


Вероятно худшая ошибка, которую любой может сделать в отношении темы оператора goto, это считать, что "структурное программирование" достигается написанием программы как мы обычно делали и потом устранить все goto. Большинство goto там изначально лишние! Что мы действительно хотим, так это задумывать наши программы таким образом, что мы даже не думаем про выражения goto, потому что реальная надобность в них почти никогда не возникает. Язык, которым мы выражаем наши идеи, сильно влияет на наши мыслительные процессы. Следовательно, Дейкстра требует новых языковых возможностей — структур, которые помогают ясному мышлению — чтобы избежать соблазна "goto" усложнений.

И это подтверждается всем моим опытом с питомниками: они поощряют чистое мышление. Они ведут к дизайну, который более надежен, легче в использовании и просто лучше со всех сторон. И ограничения помогают решать проблемы, потому что вы экономите время, не соблазняясь в сторону ненужных усложнений. Использование Трио, в самом натуральном смысле, сделало меня лучше как программиста.


Например, посмотрите на алгоритм Happy Eyeballs (RFC 8305), простой асинхронный алгоритм для ускорения установки TCP соединений. Концептуально, алгоритм несложный — вы запускаете гонку нескольких соединений, с отложенным стартом, чтобы избежать нагрузки на сеть. Но если посмотреть на лучшую Twisted реализацию — это почти 600 строк кода на Python и все еще имеет как минимум одну логическую ошибку. Эквивалент в Трио короче в 15 раз. Еще важнее, используя Трио я написал код за несколько минут, вместо месяцев, и логика верно работала с первой попытки. Я бы никогда не смог это сделать с любым другим фреймворком, даже с теми, в которых я имею намного больше опыта. Если хотите больше деталей, посмотрите моё выступление. Всегда ли будет так? Время покажет. Но выглядит перспективно.


Выводы


Популярные примитивы параллельного программирования — выражения go, функции порождающие потоки, коллбэки, Futures, Promises,… они все — вариации над goto, в теории и практике. И даже не современного одомашненного goto, но старозаветного с огнем-и-молниями goto, который игнорирует границы функций. Эти примитивы опасны, даже если их не использовать прямо, потому что они подрывают нашу способность рассуждать о потоке выполнения и составлять сложные системы из абстрактных модулей; также они мешают полезным возможностям языка, таким как автоматическая очистка ресурсов и всплытие ошибок. Поэтому, как и goto, им не место в современном высокоуровневом языке.


Питомники обеспечивают безопасную и удобную альтернативу, которая сохраняет всю мощь вашего языка, открывает новые возможности (как Трио продемонстрировал в управлении отменой задач и обработке CTRL+C) и может привести к эффектным улучшениям в читаемости, продуктивности и корректности кода.


К сожалению, чтобы сполна воспользоватся этими преимуществами, необходимо полностью удалить старые примитивы, и это, вероятно потребует создания с нуля новых фреймворков — также же, как удаление goto потребовало создания новых языков. Но как бы впечатляюще ни выглядел FLOW-MATIC в свое время, большинство из нас рады, что мы перешли на что-то лучшее. Я не думаю, что мы пожалеем о переходе на питомники, и Trio показывает, что это жизнеспособный проект для практических, универсальных асинхронных фреймворков.


Комментарии


Вы можете обсудить этот пост на форуме Trio.


по ссылке из статьи всего два сообщения:


А основной Trio форум тут: https://trio.discourse.group/

Благодарности


Большое спасибо Graydon Hoare, Quentin Pradet, and Hynek Schlawack за комментарии к черновику этой статьи. Любые оставшиеся ошибки, конечно же, остаются на моей совести.


большое спасибо пользователю berez за найденные в переводе ошибки.

Использованные материалы: Пример FLOW-MATIC кода из этой брошюры (PDF), из музея компьютерной истории.


Wolves in Action, фотограф Martin Pannier, под лицензией CC-BY-SA 2.0, обрезано.
Французский бульдог, автор Daniel Borker, под лицензией CC0 public domain dedication.


Сноски


[2] А WebAssembly даже показывает, что возможно и желательно иметь низкоуровневый ассемблерный язык без goto: ссылка, обоснование


[3] Для тех, кто вероятно не обратит внимания на этот текст, не удостоверившись заранее, что я в курсе их любимых статей, вот мой текущий список тем для обзора:
The "parallel composition" operator in Cooperating/Communicating Sequential Processes and Occam, the fork/join model, Erlang supervisors, Статья Martin Sústrik's о структурной параллельности и работа над libdill, и crossbeam::scope / rayon::scope в Rust. Мне также указали на крайне связанные с темой golang.org/x/sync/errgroup и github.com/oklog/run в Golang.
Дайте мне знать, если я пропустил что-либо важное.


[4] Если вызвать start_soon() после того, как питомник закрылся, тогда start_soon вызовет исключение, а если исключения нет, значит питомник гарантировано открыт, пока все задачи не завершатся. Если вы создаете вашу собственную систему питомников, вы должны будете внимательно управлять синхронизацией в этом месте.


Об авторе


Nathaniel J. Smith, Ph.D., работал в UC Berkeley над улучшением numpy, на данный момент состоит в команде разработчиков Python и выступает на конференциях. Идея Nathaniel о структурированнии параллельных вычислений может стать революцией и в корне перевернуть наш способ написания асинхронных программ.


Продолжение


Эта статья также совершенно случайно продолжает серию дискуссий об асинхронном программировании на Хабре:


  • Какого цвета ваша функция, где Bob Nystrom рассуждает о проблемах асинхронного программирования
  • комментария в котором всплывает интересная задача для асинхронного алгоритма, и решение на golang
  • статья Сложность простоты, где Алексей PsyHaSTe решает ту же асинхронную задачу на Haskell, Golang и C#
  • множества комментариев к ней с решением той же задачи на: Go, Go, python, C# (странно, что не написали на JS)

В итоге, как кажется, сошлись на том, что Haskell позволяет писать наиболее выразительно и чисто, пока не добавляются требования реального мира, такие как ограничения количества потоков и легкости внесения изменений в алгоритм.


Приглашаю авторов и активных участников дискуссии (Юрий Насретдинов, Аноним 0xd34df00d, Алексей) к решению асинхронной задачи, на которую автор ссылается в статье (Happy Eyeballs), на вашем любимом языке и используя ваш любимый фреймворк.


Правда ли, что Trio насколько крут? Или же Haskell и Golang заткнут его за пояс?


И кстати:

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Как лучше назвать новую концепцию «Nursery» из оригинальной статьи?

  • 38,3%Питомник31
  • 24,7%Ясли20
  • 12,4%Детский сад10
  • 0,0%Детская0
  • 34,6%Н(о|ю)рсери, да простит меня великий и могучий, но раз уж он стерпел дженерики, треды и промисы…28
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 50

    +2
    Интересно, конечно, автор сравнивает две картинки и говорит, что go и goto на картинках похожи )
    Возможно, я не уловил метафоры автора:
    тогда среда выполнения… роняет ошибку на пол
    применительно к языку Golang, среда роняет весь процесс выполнения программы и никуда ошибка не потеряется. Чтобы этого не случилось, нужно все подпереть recover. Так что, тут не совсем понятно в чем сложность обработки ошибок в горутинах.
      0

      Так речь то не только о языке Go (видимо я зря суслика на обложку поставил, и ввел всех в заблуждение), а об императивных языках, в которых описанные недостатки стоят в полный рост.

        –1
        Но ведь это не так.
        В данный момент меня больше интересует Golang, поэтому спрошу: в чем проблема контроля ошибок в горутине?
        Если не использовать defer recover, то ошибка остановит и главный поток, поэтому она никуда незаметно не денется.
        Если нужен recover, то ошибку можно отправить в канал или сохранить в лог и продолжить дальше, т.е. использовать ровно тот же подход к контролю ошибок, как и в главном потоке выполнения программы.
      +6
      В Go в стандартной библиотеке есть WaitGroup. По смыслу тоже самое, можно подождать пока все горутины отработают.
        0

        Более того, есть golang.org/x/sync/errgroup, через который можно запускать горутины, и оно ещё ошибку вернет, если она возникла у какой-то из выполняемых в группе горутин.

        +5

        Так себе. Nathaniel набрасывает на Go исключительно для громкого заголовка. Этот архитектурный астронавт накидывается на pthread_create, std::thread, ключевое слово go и забывает, что это базовые примитивы с которых начинается многопоточность.


        Дальше описывает стандартные проблемы многопотоного программирования, такие как обработка ошибок и исключений в другом потоке. Рассуждая о потоке выполнения, он все сворачивает до fork–join, т.е. полностью забивает на модели concurrently, например акторы и CSP.

          +1

          Не забивает, а изолирует в питомнике. Внутри питомника уже живут эти акторы.

            +1

            С точки зрения Joel Spolsky, отраженной в его статье, чем проще, тем лучше (и я согласен), но асинхронное программирование таки часто необходимо, и Натаниель пытается сделать его значительно проще.


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


            Заголовок действительно громковат, но это же не строгая научная статья в конце концов.

              0

              Так и решения то стандартные. Открывая Timeouts and cancellation for humans видим Cancellation token. Только пробрасывается скрыто:


              You should think of with open_cancel_scope() as creating a cancel token, but it doesn't actually expose any CancelToken object publically. Instead, the cancel token is pushed onto an invisible internal stack, and automatically applied to any blocking operations called inside the with block. So requests doesn't have to do anything to pass this through – when it eventually sends and receives data over the network, those primitive calls will automatically have the deadline applied.

              Только зачем он пишет о превосходстве своего решения на Python над примитивами из C#, Go. Примитивы на то и примитивы, что на базе них можно сделать высокоуровневые абстракции.

                0

                Пользоваться все же удобнее абстракциями высокого уровня, но вы совершенно правы, примитивы полезно знать и изучать, потому что абстракции протекают.

            +4
            Интересная тема для обсуждения.

            Переводчику стоило бы в начале статьи, а лучше в заголовке, указать что это реклама (пропаганда?) Трио.

            Странно, что автор приводит кучу примеров, но делает вид что ерланга не существует. На мой взгляд, эталонной реализации многопоточности.

            Мне кажется автор не прав в своем отношении к проблеме. Автор говорит о проблемах, которые есть исключительно в случае расшаренных изменяемых данных между потоками. Если таких данных нет — ничего, из описанных проблем, тоже нет. Но говоря только о потоках, но не данных — он лишается базы для всех своих дальнейших выводах.
              +1

              Совершенно верно, ясно, что он в курсе функциональных языков, но обходит их стороной, концентрируясь на проблемах императивных языков.

              0
              Автор статьи не понимает принципиальной разницы между параллельностью и конкурентностью.
              Это легко понять сразу из факта того что вместе поставлены
              go myfunc(); — это об конкурентности
              pthread_create — это об параллельности
                +2

                Автор говорит о потоке исполнения и многозадачности. Крутятся ли задачи на одном ядре или на разных в данном контексте не имеет значения. Ну а stackfull сопрограммы и системные потоки семантически одно и то же.

                  +2

                  Да, я даже хотел эту мысль написать в примечаниях к статье, но подумал, что это достаточно очевидно.

                    +1

                    Вы переоцениваете местную аудиторию.)

                  +1
                  А есть где-то ещё согласные именно с такой «принципиальной разницей» между этими терминами, как вы утверждаете?
                  А то, если посмотреть на типовые утверждения вида

                  > Concurrency means multiple tasks which start, run, and complete in overlapping time periods, in no specific order. Parallelism is when multiple tasks OR several part of a unique task literally run at the same time, e.g. on a multi-core processor.

                  то и go myfunc(); не запрещает запустить на другом ядре и работать с непересекающимися данными, и нитка по pthread_create() не обязана выполняться на другом ядре (и на одноядерной таки будет конкурировать с текущей)…
                    0
                    Принципиальная разница в том, разделяют задачи общие данные или нет. Если не разделяют, то при отсутствии свободных потоков их можно выполнить последовательно в вызывающем потоке. Если разделяют — например, в фоновом режиме отсылают снимки экрана в АНБ — то нет.
                      0
                      Разделяют в каком смысле?

                      Если разделяют с одновременным доступом только на чтение, то и пусть выполняются и последовательно, и параллельно. За когерентность пусть аппаратура кешей/памяти отвечает.

                      А доступ на одновременную запись должен быть запрещён строго хоть компилятором, хоть средой исполнения. А хоть и вольно/нестрого – это на усмотрение разработчика и в соответствии правилами/ограничениями языка.
                    0
                    Автор воспринимает это как разные возможности в асинхронном подходе, которые лежат «под капотом». Он вообще рассматривает другую проблему. Пришел синтаксический сахар, который все равно не решает проблему контроля flow.
                    0

                    Такое… взяв за основу то, что необходимо дождаться выполнения всех параллельных функций, автор усложняет целый спектр задач, когда требуется независимое выполнение. Ход конем с пробросом питомника выглядит как грязный хак.

                      +3
                      Спасибо за перевод.

                      Автор — клоун, я даже дочитать этот опус не смог. Коллеги выше уже отметили нулевые знания в области (непонимание concurrency, parallelism, CSP), так ещё и полное профанство в языке Go (15-минутный go tour очевидно не пройден).

                      Даже лень комментировать этот бред: «go похож на goto (нет), поэтому они одинаковые (нет)», "'go' ломает исключения, а без них ошибки не обработать" (исключений в Go нет), «каналы ещё не придуманы и не существуют», «мифические абстракции ломаются (автор не знает какие абстракции есть в Go, но уверен что они ломаются)», «go ломает автоотчистку ресурсов» (её в Go тоже нет, но автор и этого не знает).

                      Немного питонирую и могу понять, какую проблему автор «героически» решает. Но это проблема именно языка Python (и многих других к сожалению), а Go с его «go» спроектирован на базе решения этой проблемы и просто иммунен к ней (но не ко многим другим к сожалению).
                        +2

                        Я, как переводчик, вероятно ввел всех в заблуждение, поставив на обложку аватар языка Golang, в то время как автор имеет в виду Go-подобные выражения в других языках. Просто в языке Го эта концепция доведена до совершенства, и многие описанные проблемы решены или почти решены, но в остальных мейнстримновых языках — так как они изначально создавались синхронными, а параллельность прикручивали сбоку, потому как мода пошла — все описанные проблемы присутствуют

                        0
                        В поздних 60-х

                        Такие вещи всё же стоит вычитывать после гугл транслейта…
                          +2

                          Мне обидно слышать ваше предположение, так как в авто-переводчике (deepl) я переводил только отдельные слова, если не знал их значение.

                            +1
                            Даже ухитрившись решить все эти проблемы, теперь в программе две системы обработки ошибок.

                            Увы, такие вещи всё равно просачиваются в текст.
                              0

                              Я этот кусок два раза переписывал, и всё равно фигня получилась, видимо просто устал уже.

                          0
                          Поглядев из любопытства на историю версий Trio, обнаружил там любопытную запись:

                          Trio 0.6.0 (2018-08-13)
                          Features: Add trio.hazmat.WaitForSingleObject() async function to await Windows handles.

                          Выглядит так, что от низкоуровневых примитивов, ещё и привязанных к платформе, автор отказаться так и не смог.
                            +1

                            Ну так он их абстрагирует за фасадом питомников, для этого библиотеки и фреймворки и существуют, кажется.

                              0
                              Меня смутило слово features в описании и тот факт, что в ранних версиях библиотека без этого вполне обходилась. Я вообще раньше думал, что Питон — достаточно высокоуровневый язык для того, чтобы ничего не знать о примитивах Windows.

                              Ожидание события и прочие блокировки, как по мне — больше тянет на goto в параллельном программировании, чем создание новых потоков. Ну и тут говорят, что таки есть нюансы.
                                +1
                                trio.hazmat is Trio’s “hazardous materials” layer: it contains APIs useful for introspecting and extending Trio. If you’re writing ordinary, everyday code, then you can ignore this module completely. But sometimes you need something a bit lower level.

                                trio.readthedocs.io/en/stable/reference-hazmat.html
                            0

                            Вначале я подумал что это очередная статья на тему "я не умею в асинхронный код и слишком часто стреляю себе в ногу — давайте запретим и заменим чем-то новым что не достреливает до моих ног", но потом вспомнил что это перевод и воздержался от подробного разбора.

                              +2

                              Так статьи затем переводят, чтобы мы на родном языке могли их понять и обсудить.

                              +1
                              [i]Корневая идея такова: каждый раз, когда поток выполнения разделяется на несколько параллельных путей, мы должны убедится, что они соединятся снова.[/i] — я в основном занимаюсь программированием микроконтроллеров: значительная часть потоков создаются и далее взаимодействуют или не взаимодействуют между собой исходя из конкретной задачи. У части задач может и не быть конца, как такового. Питание есть — задача работает.

                              [i]Если вы не используете Assembler [2], классический, неограниченный goto ушёл в прошлое.[/i] — довольно странное суждение: в общем случае ассемблерные коды мало отличаются от кода на других языках: люди себе не враги, чтобы писать такой код, который потом еще расхлебывать придется.
                                0
                                Не вижу в статье упоминания реактивных стримов.
                                  0

                                  Первый раз такое слышу, киньте пожалуйста ссылку на хорошее описание.

                                +1
                                А ещё есть отличное решение от Интел, где все эти «питомники» (aka task_arena) как раз используются в качестве «чёрного ящика»
                                  0

                                  Да, там та же концепция, видимо идея витает в воздухе и будут появляться еще фреймворки на ее основе.

                                  –3
                                  Чтобы не использовать GO нужны мощные BREAK и CONTINUE позволющие выбрать на какой из нескольких уровней вложенных циклов нужно выйти, а без этого приходиться использовать GO.
                                    –3
                                    За что минус то?
                                    Не во всех языках есть break и continue с выходом на выбранный уровень цикла.
                                    Можно конечно, извратнутся присваивая некоторую переменную указывающую на какой уровень цикла нужно выйти, и в начале каждого цикла проверять значение, но это изврат.
                                      +2

                                      Что break, что continue не умеют запускать асинхронную сопрограмму, в отличие от go. Следовательно, go нельзя заменить ни на break, ни на continue.

                                      0

                                      Вы, видимо, хотели написать "GOTO"?

                                      0
                                      в с++ «менеджеры контекста», т.е. деструкторы отлично работают с goto. и с потоками (го). но судя по этой длинной статье в языках без деструкторов тяжело
                                        0

                                        В Питоне тоже есть деструкторы, и менеджерами контекста они не являются...

                                        0
                                        Если я вызову некий библиотечный метод который запскает дочерние такски через «asyncio.ensure_future», этот nursery как-то их отловит?
                                          0

                                          Насколько я знаю — нет. Все параллельные задачи надо запускать через объект питомник (можно также питомник в питомнике)

                                          +1
                                          Интересная статья. Интересная философия. Интересная реализация, но…
                                          Итак, это была теория. А как это работает на практике?

                                          И дальше пустота!
                                          И этим всё сказано — в статье явно не хватает примеров, особенно во второй её половине и тем более в конце — откуда и взята эта цитата. Практика то и не описана вовсе? Много рассуждений о попыток сравнения (увы абсолютно пустых и неконкретизированных попыток сравнения), а реальных примеров нет. Код очень скуден — доманстрация механизма напрочь отсутсвует. В начале стать есть интересные диаграммы — но дальше — идёт достаточной сухой текст почти без примеров и демострации как это всё работает. Есть критика других яызков — но нет примеров, показывающих их проблему (не говоря уже о том, что нет примеров, показывающих как эту проблему решают на этих языках — чтобы показать что решение на Trio действительно выглядет лучше). Особенно много отсылок к горутинам языка Golnag, но нет ни одного примера проблематики именно на Golang. Как и практически нет сравнения с языокм Erlnag/Elixir — считающимися практически эталоном организации надёжного и масштабируемого асинхронного выполнения кода. Увы, нет, сравнения с новомодным языком Kotlin — а там тоже есть интересная логика распараллеливания через корутины.
                                          Что это? Вина переводчика? Ведь в ссылкам на англоязычный ресурс примеров куда больше (хотя — как мне показалось — они сумбурны и так же — это просто код на Python, без сравнения с другими языками). Да и ссылки на цельный оригинал нет? Что это — перевод-сборная солянка? В общем — любопытная технология — но преимущества показаны не так хорошо, чтобы всецело следовать данному подходу и применять в Python, не говоря уже о том, чтобы вызвать желание портировать библиотеку на другие языки программирования! Хотя, как идеология для новых языков или развития существующих языков со слабой/отсутствующей поддержкой управляемой асинхронности — такая философия может быть полезна к применению при развитии архитектуры этих языков. Но, как уже сказал, сила статьи недостаточна, чтобы сразу браться за внедрение данного подхода в ядро языка или хотя бы в состав базовых библиотек.
                                            0

                                            Действительно, в этой статье примеров кода маловато, но два примера с обьяснениями можно посмотреть в исполнении автора на youtube, также в блоге автора есть статьи, где примеров с искользованием Трио побольше, вот например, или вот статья про проблемы асинхронного программирования (тоже с большим количеством примеров), причем все эти ссылки есть в переведенной статье.


                                            А данная статья упирает на логическо/историческое объяснение авторского решения, и примеры даны минимальные, чтобы просто объяснить суть. И мне кажется, это хорошо, чтобы не отвлекатся слишком сильно на погружение в дебри кода.


                                            Да и ссылки на цельный оригинал нет?

                                            В самом верху статьи, возле плашки "перевод" — кликните по имени автора, и попадете на оригинальную статью.


                                            ни одного примера проблематики именно на Golang. Как и практически нет сравнения с языокм Erlnag/Elixir

                                            Да, это слабое место статьи.


                                            нет примеров… чтобы показать что решение на Trio действительно выглядет лучше

                                            Как раз играюсь с библиотекой, вероятно позже добавлю пару примеров.


                                            P.S. Спасибо за подробный комментарий

                                              +1
                                              Сравнения с новомодным Kotlin нет, потому что заметка Натаниэля вышла до релиза котлиновской библиотеки корутин. И наоборот, в каждом своём выступлении руководитель разработки котлиновских корутин Роман Елизаров ссылается на пост в блоге Натаниэля. Тут, например.

                                              Заметка Натаниэля, с моей точки зрения, ценна тем, что тут автор чётко формулирует новую концепцию, опуская детали реализации и другие несущественные подробности. С деталями реализации можно познакомиться, перейдя по ссылкам на страничке-агрегаторе.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое