Вот у вас, например, недостаточно просто объявить cor_http_reponse_t и затем вызвать cor_http_response_set_body. Нужно еще предварительно вызвать cor_http_response_init.
Нельзя просто после ev_run сделать return, нужно еще предварительно вызывать cor_http_delete.
Нужно объявлять переменную loop со специальным значением.
Это все детали, которые легко упустить. А потом искать проблемы. Именно поэтому «простой» код на C получается объемнее и требует к себе большего внимания.
Именно поэтому вас и просили написать таки те самые 100 строк кода на C. Дабы вы сами в этом смогли убедиться.
Это не верная аналогия. Да и вообще, сам факт того, что приходится прибегать к аналогиям уже показателен.
Но давайте попробуем на аналогии: в статье говорится, что варить кофе эспрессо быстрее и удобнее, чем варить в турке. И приводятся примеры и того, и другого. А потом приходите вы и говорите: «что-то я не понимаю, как варить кофе эспрессо, по-моему, если заваривать кофе в чайничке, то будет еще проще и быстрее». И когда вас просят продемонстрировать, как вы будете это делать, вы говорите что «это мое мнение, а вообще вон за углом в знаменитой кофейне так варят и нормально получается».
Вы понимаете разницу между мнением и утверждением?
Я не понимаю зачем нужно высказывать мнение, если даже автор не может его подтвердить.
Вот обработка соедниений в nginx:
Ну а пример из статьи с этой самой красотой как будет выглядеть? И вообще-то такие потроха нужно сравнивать с потрохами Asio, а не с кодом, который Asio использует.
Не у всех хватает дыхания читать простыни из «простого» сишного кода. Ну и речь не о том, а о ваших словах «Уверен, что 100 строк C-ного кода будут понятее, чем приведённый пример». Без реального сравнения непонятно, откуда такая уверенность может появится у кого-то еще.
Неудобно. Так ключик в командной строке поменял с -t 2 на -t 8 и запросы полетели не в 2 потока, а в 8-мь, при этом ничего не нужно делать с исходным файлом запросов, в котором этих запросов может быть под миллион, а то и больше.
Ну и повторю еще раз: вы, лично вы, можете видеть что угодно и где угодно. Считаете вы, что акторы Хьюита — это частный случай dataflow actors — никто вам этого не запретит. Статья не про это, а про то, что делать в случае акторов Хьюита.
Разводить демагогию на тему того, что одноколесный, двух-колесный и трех-колесный велосипеды — это все частные случаи для понятия «велосипеда», и еще более частные случаи понятия «транспортного средства», мне не интересно. Поскольку на практике разница между всеми этими типами велосипедов просто значительная.
Вот так же и с акторами, когда их пытаются применить в задачах посложнее студенческой курсовой.
Вот об этой. Суть в том, что B не должен знать ни про C, ни про D, ни про E. Да и C, D и E могут узнать про B только на короткий момент времени, после чего забудут о нем.
Ну так первая имплементация из перечисленных там — это Akka Streams и есть, поскольку сам Reactive Manifesto делался, в том числе, и людьми, стоящими за Akka. В том числе и для продвижения Akka.
Тем не менее, посмотрите на спецификацию этих самых reactive streams. Там subscriber должен вызвать Publisher.subscribe для того, чтобы получать сообщения от конкретного publisher-а.
Что для моего примера выше означает, что актор B должен сперва подписаться на паблишеров C, D, E и всех прочих. Это совсем не та ситуация, о которой я говорю.
А отличается тем, что общее число таких запросов ограничено общим числом акторов.
А общее число акторов мы знаем откуда?
Вы, походу, слишком долго варитесь в области dataflow-программирования. Это там специфика такая, что количество вычислительных сущностей (узлов, процессов) и их взаимосвязи известны заранее.
Отсюда и решение — пусть актор (точнее, один из его входов) сам выступает в качестве запроса, а очередь запросов сделать в виде списка, а не массива.
Либо вы предлагаете то, чего я не понимаю, либо ваша идея в том, чтобы самих акторов прописывать в интрузивный список. Что есть отстой. Ибо работать будет только для ограниченного типа сценариев (например, когда понятно, что запрос типа X к актору B любой другой актор не может отсылать более одного раза.
Вот только в Intel TBB понятие актора не используется, насколько я помню.
Так что исходный тезис о том, можно ли отождествлять dataflow и actor model, все еще нуждается в доказательстве.
Если вы посмотрите на back-pressure из Akka, то увидите, что этот back-pressure сделан не для акторов, а для Akka Streams, дополнительной штуке, которая существует сбоку от акторов.
Вот у вас, например, недостаточно просто объявить cor_http_reponse_t и затем вызвать cor_http_response_set_body. Нужно еще предварительно вызвать cor_http_response_init.
Нельзя просто после ev_run сделать return, нужно еще предварительно вызывать cor_http_delete.
Нужно объявлять переменную loop со специальным значением.
Это все детали, которые легко упустить. А потом искать проблемы. Именно поэтому «простой» код на C получается объемнее и требует к себе большего внимания.
Именно поэтому вас и просили написать таки те самые 100 строк кода на C. Дабы вы сами в этом смогли убедиться.
Как-то даже на таком тривиальном примере видно, что C-шный код внимания к себе требует побольше.
Очевидным является то, что бездоказательное мнение не имеет никакого веса и смысла его высказывать не было.
Но давайте попробуем на аналогии: в статье говорится, что варить кофе эспрессо быстрее и удобнее, чем варить в турке. И приводятся примеры и того, и другого. А потом приходите вы и говорите: «что-то я не понимаю, как варить кофе эспрессо, по-моему, если заваривать кофе в чайничке, то будет еще проще и быстрее». И когда вас просят продемонстрировать, как вы будете это делать, вы говорите что «это мое мнение, а вообще вон за углом в знаменитой кофейне так варят и нормально получается».
Ну а пример из статьи с этой самой красотой как будет выглядеть? И вообще-то такие потроха нужно сравнивать с потрохами Asio, а не с кодом, который Asio использует.
В вашем же случае идет голословное утверждение.
Ну и повторю еще раз: вы, лично вы, можете видеть что угодно и где угодно. Считаете вы, что акторы Хьюита — это частный случай dataflow actors — никто вам этого не запретит. Статья не про это, а про то, что делать в случае акторов Хьюита.
Разводить демагогию на тему того, что одноколесный, двух-колесный и трех-колесный велосипеды — это все частные случаи для понятия «велосипеда», и еще более частные случаи понятия «транспортного средства», мне не интересно. Поскольку на практике разница между всеми этими типами велосипедов просто значительная.
Вот так же и с акторами, когда их пытаются применить в задачах посложнее студенческой курсовой.
хотелось увидеть что-то уровнем повыше студенческой курсовой.
Тем не менее, посмотрите на спецификацию этих самых reactive streams. Там subscriber должен вызвать Publisher.subscribe для того, чтобы получать сообщения от конкретного publisher-а.
Что для моего примера выше означает, что актор B должен сперва подписаться на паблишеров C, D, E и всех прочих. Это совсем не та ситуация, о которой я говорю.
А общее число акторов мы знаем откуда?
Вы, походу, слишком долго варитесь в области dataflow-программирования. Это там специфика такая, что количество вычислительных сущностей (узлов, процессов) и их взаимосвязи известны заранее.
Либо вы предлагаете то, чего я не понимаю, либо ваша идея в том, чтобы самих акторов прописывать в интрузивный список. Что есть отстой. Ибо работать будет только для ограниченного типа сценариев (например, когда понятно, что запрос типа X к актору B любой другой актор не может отсылать более одного раза.
Так что исходный тезис о том, можно ли отождествлять dataflow и actor model, все еще нуждается в доказательстве.
Если вы посмотрите на back-pressure из Akka, то увидите, что этот back-pressure сделан не для акторов, а для Akka Streams, дополнительной штуке, которая существует сбоку от акторов.