Как вы пишете асинхронный, интерактивный код?

Тебе подойдет любой реактивный фреймворк. https://www.reactivemanifesto.org/

Хотя, если производительность не важна, то можно на BPEL мышкой натыкать. Будет вполне кроваво-энтерпрайзно. https://en.wikipedia.org/wiki/List_of_BPEL_engines

monk, а вот здесь продолжения из схемки случайно не разрулят всю ситуацию?

Паттерн Command же.

Ты про подобное спрашиваешь?
https://docs.python.org/3/library/asyncio-task.html#asyncio.Task.cancel

Да, почти оно. Только не пойму почему Task помечен как not thread-safe.

Нашёл CancellationToken в C#, то там пример кода наркоманский. Нужно мнение специалиста: WitcherGeralt

Это особенность реализации, все зависит от рантайма.

В питоне несколько рантаймов?

Ну как минимум есть pypy.

Elixir c агентами, для асинхронного программирования ничего лучше нет.

То, что вы описываете, выглядит как актор.

А, вы про саму реализацию.

Как вы пишете асинхронный, интерактивный код?

Не пишу такой код

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

Ты мне должен новые глаза. Не понятно зачем токен пробрасывается дважды, первый раз в фабрику, где он и так присваивается треду, и в старт во второй раз, и почему cancel делается не на нём, а на source, который в сущности тоже пробрасывается, но уже через замыкание. Похоже на какой-то костыль.

А вообще, в managed языках как-то даже не интересно. Я так в питоне делал через settrace, но оверхед, конечно, получался знатный.

Языки на BEAM? Вроде все пункты присутствуют.

может что-то почитать на тему архитектуры распределенных систем?

в общем случае это процессы или треды, общающиеся сообщениями по каналам посредством p2p или бродкастом. а никакие не колбеки и прочие хехе замыкания.

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

А если в стиле «вернуться из асинхронного вызова в вызывающий код», то продолжения рулят, но именно для этой задачи во многих языках сделали async/await.

А так всё, что перечислено, в Racket реализовано стандартной библиотекой:

1. break-thread
2. thread-suspend и thread-resume
3. thread-send и thread-receive
4. thread видит все переменные в контексте запуска
5. может
6. не превращается

погляди как в винде эвенты обрабатываются (кстати там можно TCP ловить эвентами, что ОЧЕНЬ удобно)

именно для этой задачи во многих языках сделали async/await

К сожалению, я так и не въехал в них. Времени всё не было. Есть какое-то толковое объяснение?

Ты описал акторы.

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

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

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

мне очень понравилось наглядный образ с цветными функциями:

http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

(перевод: https://habr.com/ru/post/466337/ )

Это же новый goto.

Потому, что в go его нет?

В Go и не нужно, ибо CSP.

Не вижу связи.

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

Ты какую-то ахинею спросил. Я, видимо, не так её распарсил.

Покажи csp на го. Если ты про отправку сообщений, то тут ничего нового и в моей задаче это никак не поможет.

Давай конкретней. Что именно ты хочешь увидеть?

Причём здесь твоя задача? Я тебе одним словом описал всю суть async/await. Вообще безотносительно неё.

https://learn.javascript.ru/async-await

или

https://rust-lang.github.io/async-book/03_async_await/01_chapter.html

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

Если внутри такой функции запускается другая async функция, то её можно подождать (и получить её результат) написав перед вызовом await.

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

В растовской реализации есть странность: при вызове асинхронной функции из другой асинхронной функции новый поток автоматически не запускается. Есть костыль: https://rust-lang.github.io/async-book/06_multiple_futures/02_join.html

В реализации C# у результата асинхронной функции есть поле Result, при обращении к которому выполнение вызывающего блокируется до окончания вычисления асинхронной функции. Эдакий thread-join. В целом, вариант C# наиболее удобный для использования.

Как запустить n горутин последовательно, с возможностью остановить выполнение по условию?

Псевдокод:

await fun1()
let result = await fun2()
if result.is_ok()
    await fun3()
else 
    await fun4()

При этом каждая funN может завершится по глобальному флагу. То есть я могу жмакнуть Cancel пока выполняется fun2 и код не дойдёт до if result.is_ok.

Растовская книга не дописана. Но я её уже читал и так ничего и не понял.

Если на пальцах

Это как раз понятно. Не ясно как прервать await. Передавать в каждую функцию «канал»? Будет выглядеть жутко.

То есть для примера, я посылаю запрос и он висит 5 мин. Я хочу его отменить. Как это сделать, если прога уже и так висит в await.

здесь вычисляем result

Я могу прервать этот этап извне?

Но я не предлагал тебе решать твою задачу на Go.

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

Совокупность пунктов 2 и 3 питонические таски тоже исключает.

По его требованиям ты должен на каждую горутину ещё и канал с селектом для прерывания воткнуть.

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

async/await как и горутины для этого не предназначены. То есть, можешь, но отдельными костылями.

Полностью готовое решение вот: https://docs.racket-lang.org/reference/threads.html

Значит на каждой ступени должна быть обработка прерывания.

Как я уже сказал выше, в питоне это можно сделать с помощью settrace на потоке. Но это колхоз.

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

Полностью готовое решение вот

В racket какие-то свои потоки или вы намекаете что всё нужно делать самому?

Ну так у меня так и сделано. Но это callback hell.

Так вот я и не пойму для чего они тогда предназначены

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

Ок, принимается.

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

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

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

Свои потоки. Реализованы как зелёные, что снимает большую часть проблем с атомарностью операций.

Также всё перечисленное легко реализовать на Erlang. Процессы асинхронные, можно останавливать через kill. Внутри процесса можно ловить kill через receive и нормально обрабатывать завершение процесса.

сам тред ты прервать не можешь

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