Я как раз и говорю о плюсах...

О, оказывается вот это вот все было о плюсах. Ну Ok.

Сэр не в курсе как с этим принято бороться в крестах?

Да куда уж мне.

Один толковый товарищ говорил «A Computer is a state machine. Threads are for people who can't program state machines»

Алан троллил.

Наверное тот товарищ таки имел в виду вот эти вот somethingElse. Трудность втулить somethingElse заставляло народ думать «Чето не клеится. А нужно ли оно вообще?» после чего обычно приходило озарение и более грамотное решение. А теперь народ вообще думать перестал и лепит свои макароны.

Какое отличное вырывание из контекста. Пожалуйте в игнор, толстячок.

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

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

Вместо зеленых потоков можно использовать классы - машины состояний. Они будут еще компактнее и нету вероятности переполнить стек.

Не уверен что вызов колбека легче «переключения зеленого контекста». И гринтред мало чем отличается от инстанса КА.

Не уверен что вызов колбека легче «переключения зеленого контекста»

Обычного коллбека указателя на функцию в С++? Или из ядра ОС? Если первое, то наверное таки легче. Как минимум меньше в стек помещать и не нужен барьер памяти

инстанса КА.

Что такое КА?

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

Как минимум меньше в стек помещать и не нужен барьер памяти

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

Что такое КА?

конечный автомат же

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

пруф?

Один толковый товарищ говорил «A Computer is a state machine. Threads are for people who can't program state machines»

Тут есть один нюанс: таких ЯП, которые были бы достаточно абстрактными, чтобы обходиться без явного программирования тредов руками почти нет. А те, что есть прямо сейчас — сплошь предметно-ориентированные, вроде SQL и прочих декларативных.

В lkml

Есть ли готовые реализации

QThread, очевидный.

а где конкретно?

На сколько я знаю, libthread из plan9 готовая реализация. Есть порт под linux.

Насколько перфоманс важен? Может не париться и прикрутить сбоку Lua?

QThread, очевидный.

Ты грибов что ли объелся, что у тебя QThread позеленел?

go-style concurency in c

http://libmill.org
http://libdill.org

Один толковый товарищ говорил «A Computer is a state machine. Threads are for people who can't program state machines»

Лолшто. А как ты собираешься многозадачность реализовывать тогда, с отдельным контекстом для каждой задачи? А как реализуешь работу нескольких пользователей на одной машине? Твой товарищ случайно не IBM 7094 программировал?

Все правильно он сказал про переключение контекста.

Есть ли готовые реализации

QThread, очевидный.

фейспалм.obj

КА не так уже и плохи. Не понимаю почему они так трудно даются народу, и народ требует корутин.

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

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

Веберы, сэр.

CPC, aka Continuation Passing C (CPC)

сайт

оттуда см. Hekate — торрент клиент как пример приложения, использующий это на green threads

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

читай про сопрограммы, множественные точки входа, нелокальные выходы (non-local exits) и сопутствующие замыкания/продолжения для реализации сопрограмм, конечных автоматов и прочая, прочая, прочая

также Хоара про Occam и CSP. также Карла Хьюитта про акторы, в первоначальном смысле. оттуда про смоллток в смысле акторов Хьюитта, и далее — про Scheme как язык реализации акторов в лиспе, и ООП через замыкания.

да не делают конечные автоматы код сложнее.

см. презентацию роберта пайка про устройство компилятора через goroutines, и реализацию КА через сопрограммы/продолжения/etc

код пишется почти такой же, как и для функций. только это сопрограммы. получается КА.

также см. например на хабре про «порталы и корутины», как они яндекс.браузер писали: обмазавшись бустом, написали аналог горутин в с++.

Где почитать про подобную архитектуру и зеленые потоки?

читай ту cтатью на хабре, про розовую козу из фильма «Десятое королевство»: часть2 часть1

Опыт из других языков программирования — это вещь хорошая. Но каким боком node/twisted/tornado к C++?

ну хотя бы посмотри про CPC, вот тебе ответ на «каким боком замыкания связаны и сопрограммы, и старая сишка».

есть общий принцип. его (если, конечно, понимать) можно реализовать хоть в node/twisted/tornado, хоть в лиспе, хоть в MUMPS, хоть, внезапно, даже и в С++.

а то по-твоему выходит что С++ это такая ойкумена, заповедних непуганных программистов до которых общеизвестные вещи из Computer Science 70-х годов (те же сопрограммы или CSP Хоара, да вот хотя бы и акторы Хьюитта с агентами) доходят с опозданием лет на 40-50.

или не доходят, вообще. если письма не доходят — почта не виновата же.

дело не в С++, а в понимании общих принципов.

Мы говорили о КА vs coroutines в плане читабельности/понимабильности/сопровождабильности кода.

совершенно одинаково. например, см. презентацию пайка про устройство компилятора, там ещё лексер на горутинах. КА реализован как набор сопрограмм, которые выглядят как функции и практически как обычный нисходящий рекурсивный парсер (rdp).

если смотреть с точки зрения сахара «функция-корутина», выглядит одинаково. и КА становится гораздо проще читаемым, без всей этой обычной лапши вот.

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

Я не пытался в этом треде говорить про теорию. Надеюсь, с этим Ok.

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

например, как реализовать корутины, рефлексию, интроспекцию/интерцессию, метаклассы и метаобъектный протокол на С++.

агентов, акторов, корутины и КА те же.

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

ты-то со своим агентским фреймворком — теми же акторами Хьюита и нижележащей computer science (и её применениями): имхо, просто обязан интересоваться.

на некотором уровне абстракции — КА, корутины, замыкания/продолжения, акторы, агенты, коллбеки, thunk'и и octopus stack'и ---- это всё об одном и том же.

с разных точек зрения.

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

чтобы не переполнить стек, можно использовать устранение хвостовой рекурсии, например. и то же CPS преобразование, например.

а так, да — класс, КА и продолжения, акторы — это всё разные «машины состояний». на разных уровнях абстракции по разному выраженные.

А как ты собираешься многозадачность реализовывать тогда, с отдельным контекстом для каждой задачи?

define: «контекст задачи». что это? и подбери по вкусу нужную абстракцию: акторы, корутины, КА, продолжения.

а так вообще да, ежели конечных автоматов несколько — Dataflow architecture рулит.

вообще единой тактовой частоты не должно быть, ИМХО. нужна асинхронная аппаратная архитектура, для каждого блока — свой КА, свой dataflow и своя частота.

см. про «конечные автоматы Л.Мараховского», например.

А как реализуешь работу нескольких пользователей на одной машине?

да хотя бы как в MUMPS-ах, на сопрограммах.

корутины на Duff Device, C

ссылка

О, в дополнение к анонiмусу и царю, в тред подтянулся и анонимный тимлид.

вот тебе ответ на «каким боком замыкания связаны и сопрограммы, и старая сишка».

Я задавал не этот вопрос. Мой вопрос был в том, насколько применим отрицательный или положительный опыт работы с зелеными потоками в фреймворках на языках с GC для оценки сложности работы с зелеными потоками в C++.

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

Как это не станно — asio. Тормозной, как слоупок, тупейшая реализация... Но пихнут в стандарт, скорее всего (пусть и в слегка модифицированном виде).

Из альтернатив, есть folly io (обёртка libevent) и seastar.

В C++ никогда не будет полноценной реализации зелёных потоков. Проблема в том, что зелёный поток может нахулиганить и заблокировать аппаратный поток. Способов нахулиганить — масса, начиная от бесконечного цикла, заканчивая вызовом блокирующегося сисколла.

Без полноценного IO-менеджера, даже не стоит начинать. Но, и это половинчатое решение. Без поддержки языкового рантайма возможна только кооперативная многозадачность.

Никто в здравом уме не пойдёт на *такое* усложнение. А если пойдут, то C++ потеряет своё главное преимущество: беспрепятственное взаимодействие с «реальным миром».

Резюмируя, хочешь зелёные потоки, соглашайся либо на ВМ, либо на сверхсложный языковой рантайм. Взаимодействие с «реальным миром», в любом случае, только через FFI.

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

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

ты-то со своим агентским фреймворком — теми же акторами Хьюита и нижележащей computer science (и её применениями): имхо, просто обязан интересоваться.

Вы еще папу своего детей делать поучите.