Сообщение Re[9]: Почему Эрланг от 05.06.2015 14:34
Изменено 05.06.2015 14:55 BulatZiganshin
Здравствуйте, so5team, Вы писали:
S>У меня нет такой идеи. Даже в первом своем сообщении в этой теме в качестве примера фреймворка для C++ был приведен фреймворк Synca, который как раз сопрограммы и использует.
среди штук 5 акторных бибилотек. при этом ты ни словом не упомянул наиболее известные tbb/ppl/boost.coroutine и скаал что подход с потоками принципиально неприменим в C++. на мой же взгляд, акторы — это малопопулярная парадигма, а основная как раз сейчас — task paralleleism к постекпенным переходом к асинку (stackful/stackless coroutines)
BZ>>чем отличаются акторы от task parallelism, я пока не в курсе
S>В task parallelism, если я правильно помню, есть однородный поток задач, которые обрабатываются одним и тем же образом. Грубо говоря, идет поток текстовых сообщений, которые нужно зашифровать и подписать.
один вариант — это дерево задач, порождающих задачи и ждущих результата их исполнения. c++11 futures с доп. операциями типа waitAll и then. второй — это статичный граф задач, через которые текут потоки сообщений. в обоих случаях понятно как распространять исключения. в общем-то, мне кажется и в sobj это можно сделать — если кто-то подписался на сообщения от скончавшегося актора, то вместо очередного сообщения возбуждаем исключение в получателе. вероятно, в вашей скада-системе это просто незачем, да и вообще в моих по крайней мере задачах publish-subscribe имеет смысл только для доп. функционала (ui, logfile), а граф управления выглядит иначе
S>У меня нет такой идеи. Даже в первом своем сообщении в этой теме в качестве примера фреймворка для C++ был приведен фреймворк Synca, который как раз сопрограммы и использует.
среди штук 5 акторных бибилотек. при этом ты ни словом не упомянул наиболее известные tbb/ppl/boost.coroutine и скаал что подход с потоками принципиально неприменим в C++. на мой же взгляд, акторы — это малопопулярная парадигма, а основная как раз сейчас — task paralleleism к постекпенным переходом к асинку (stackful/stackless coroutines)
BZ>>чем отличаются акторы от task parallelism, я пока не в курсе
S>В task parallelism, если я правильно помню, есть однородный поток задач, которые обрабатываются одним и тем же образом. Грубо говоря, идет поток текстовых сообщений, которые нужно зашифровать и подписать.
один вариант — это дерево задач, порождающих задачи и ждущих результата их исполнения. c++11 futures с доп. операциями типа waitAll и then. второй — это статичный граф задач, через которые текут потоки сообщений. в обоих случаях понятно как распространять исключения. в общем-то, мне кажется и в sobj это можно сделать — если кто-то подписался на сообщения от скончавшегося актора, то вместо очередного сообщения возбуждаем исключение в получателе. вероятно, в вашей скада-системе это просто незачем, да и вообще в моих по крайней мере задачах publish-subscribe имеет смысл только для доп. функционала (ui, logfile), а граф управления выглядит иначе
Re[9]: Почему Эрланг
Здравствуйте, so5team, Вы писали:
S>У меня нет такой идеи. Даже в первом своем сообщении в этой теме в качестве примера фреймворка для C++ был приведен фреймворк Synca, который как раз сопрограммы и использует.
среди штук 5 акторных бибилотек. при этом ты ни словом не упомянул наиболее известные tbb/ppl/boost.coroutine и сказал что подход с потоками принципиально неприменим в C++. на мой же взгляд, акторы — это малопопулярная парадигма, а основная как раз сейчас — task paralleleism к постепенным переходом к асинку (stackful/stackless coroutines)
S>В task parallelism, если я правильно помню, есть однородный поток задач, которые обрабатываются одним и тем же образом. Грубо говоря, идет поток текстовых сообщений, которые нужно зашифровать и подписать.
один вариант — это дерево задач, порождающих задачи и ждущих результата их исполнения. c++11 futures с доп. операциями типа waitAll и then. второй — это статичный граф задач, через которые текут потоки сообщений. в обоих случаях понятно как распространять исключения. в общем-то, мне кажется и в sobj это можно сделать — если кто-то подписался на сообщения от скончавшегося актора, то вместо очередного сообщения возбуждаем исключение в получателе. вероятно, в вашей скада-системе это просто незачем, да и вообще в моих по крайней мере задачах publish-subscribe имеет смысл только для доп. функционала (ui, logfile), а граф управления выглядит иначе
S>У меня нет такой идеи. Даже в первом своем сообщении в этой теме в качестве примера фреймворка для C++ был приведен фреймворк Synca, который как раз сопрограммы и использует.
среди штук 5 акторных бибилотек. при этом ты ни словом не упомянул наиболее известные tbb/ppl/boost.coroutine и сказал что подход с потоками принципиально неприменим в C++. на мой же взгляд, акторы — это малопопулярная парадигма, а основная как раз сейчас — task paralleleism к постепенным переходом к асинку (stackful/stackless coroutines)
S>В task parallelism, если я правильно помню, есть однородный поток задач, которые обрабатываются одним и тем же образом. Грубо говоря, идет поток текстовых сообщений, которые нужно зашифровать и подписать.
один вариант — это дерево задач, порождающих задачи и ждущих результата их исполнения. c++11 futures с доп. операциями типа waitAll и then. второй — это статичный граф задач, через которые текут потоки сообщений. в обоих случаях понятно как распространять исключения. в общем-то, мне кажется и в sobj это можно сделать — если кто-то подписался на сообщения от скончавшегося актора, то вместо очередного сообщения возбуждаем исключение в получателе. вероятно, в вашей скада-системе это просто незачем, да и вообще в моих по крайней мере задачах publish-subscribe имеет смысл только для доп. функционала (ui, logfile), а граф управления выглядит иначе