[life.cinema] Очередной кинообзор (2016/12)

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

В конце туннеля (Al final del túnel, 2016). Мне очень понравилось. Можно, конечно, придраться к ряду моментов. Но просто не хочется.

Изгой-один: Звездные войны. Истории (Rogue One, 2016). Пожалуй, самое достойное продолжение саги "Звездные войны". Как по мне, так на голову выше прошлогодних ЗВ-7. Кроме довольно неожиданного для голливудского фильма финала меня еще очень порадовала тщательность проработки мелких деталей.

Спектральный (Spectral, 2016). Красочно, динамично. Если не вдумываться в сюжет, то очень даже пристойный фантастический боевик.

Новая эра Z (The Girl with All the Gifts, 2016). Хорошее дополнение в копилку фильмов про шустрых зомби, от которых не так-то просто отбиться.

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

Меня зовут Джиг Робот (Lo chiamavano Jeeg Robot, 2015). Странный фильм, который оставляет ощущение "что же это было?" Причем в хорошем смысле. Вроде как по сюжету это сказочка для детей. Но сцены насилия и секса явно говорят о том, что фильм рассчитан на взрослую аудиторию. Вот и получается очень своеобразная сказка для взрослых.

Инкарнация (Incarnate, 2016). Двойственные ощущения. С одной стороны достойный образчик жанра "изгнания демонов". Но чего-то не хватило. Да и самый-самый финал оказался слишком предсказуем.

Инферно (Inferno, 2016). Более чем посредственно. Похоже, авторы фильма сами понимали, что сюжет еще более бредовый и слабый, чем в двух предыдущих частях, поэтому им пришлось пойти на трюк с временной амнезией главного героя. Что сделало происходящее на экране еще бредовее.

Человек человеку волк (Dog Eat Dog, 2016). Редкой укуренности фильм. И если с участием Николаса Кейджа все понятно, он сейчас во всяком дерьме снимается, то вот как туда занесло Уиллема Дефо -- вот это загадка.

[prog.thoghts] Еще несколько слов на тему однопоточного SObjectizer Environment

Тема однопоточного SObjectizer Environment сидит в голове уже довольно давно. К сожалению, она не так проста, как это представлялось ранее. Поэтому руки дошли только сейчас.

Почему тема не так проста. Имеет смысл рассматривать три ситуации:

[prog.thougths] Разрешать ли использование private dispatchers с однопоточным SObjectizer Environment?

В процессе работы над SO-5.5.19 возник вопрос, при поиске ответа на который хотелось бы учесть не только лишь собственное мнение. Так что комментарии всячески приветствуются.

Суть вот в чем. В SO-5.5.19 делается поддержка однопоточного SObjectizer Environment. Однопоточный -- это значит, что такой SOEnv не создает никаких новых рабочих нитей, а все свои операции (т.е. обслуживание событий агентов, таймеров и операций дерегистрации коопераций) выполняет на той нити, на которой однопоточный SOEnv был запущен. Грубо говоря, запустили SOEnv на главной нити приложения, и все события происходят только на главной нити.

Можно отдельно разговаривать о том, зачем и когда такое может потребоваться. Но речь сейчас не об этом. Будем считать, что однопоточный SOEnv нужен, а значит его следует сделать. Но тут всплывает проблема диспетчеров.

Одна из отличительных черт SO-5 -- это возможность создавать экземпляры дополнительных диспетчеров и привязывать агентов к этим диспетчерам. Например, можно создать экземпляр thread_pool диспетчера и привязать 100500 агентов к этому диспетчеру. Потом создать экземпляр active_obj диспетчера и привязать еще пять агентов к нему (каждый агент при этом будет работать на своей собственной нити). А потом создать экземпляр prio_one_thread::strictly_ordered диспетчера и привязать к нему еще 50 агентов. В итоге в SOEnv окажется сразу несколько диспетчеров и куча агентов, каждый из которых работает на своем диспетчере.

Диспетчеры в SO-5 делятся на два вида: public и private диспетчеры.

У public диспетчера должно быть уникальное имя. Экземпляр public диспетчера явным образом регистрируется в SOEnv вместе со своим уникальным именем. И затем по этому имени может быть получен из SOEnv. Грубо говоря, SOEnv знает про все public-диспетчеры. Более того, SOEnv сам запускает и останавливает public диспетчеры.

А вот у private диспетчера имени нет. И экземпляр private диспетчера в SOEnv не регистрируется. Поэтому SOEnv вообще не знает, сколько private диспетчеров существует в данный момент. Соответственно, SOEnv не управляет private диспетчерами.

Собственно, вопрос такой: если пользователь запускает у себя в приложении однопоточный SOEnv, то можно ли разрешать пользователю создавать private диспетчеров для такого SOEnv и привязывать агентов к private диспетчерам в рамках этого SOEnv?

Интересует ответ на этот вопрос с концептуальной точки зрения.

С одной стороны, странным выглядит желание создавать дополнительные private диспетчеры, если выбран однопоточный SOEnv. Казалось бы: хочешь иметь private диспетчеры -- создавай многопоточный SOEnv, а если потребовался именно однопоточный SOEnv, то не создавай private диспетчеры. Просто и логично.

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

Получается, что если пользователю нужен однопоточный SOEnv именно для того, чтобы SOEnv не создавал своих собственных нитей для таймера и дерегистрации коопераций, то ничего не мешает пользователю создавать дополнительных private диспетчеров. Пользователь экономит ресурсы на основных операциях SO-5, за счет чего освобождает эти самые ресурсы для нужных ему private диспетчеров. Не просто, но вроде логично.

---

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

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

[prog.c++] Разбор asfikon's "C vs C++". Часть 5.

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

Приступим.

[prog.c++] Разбор asfikon's "C vs C++". Часть 4.

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

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

Итак, приступим.

[prog] Вопрос по организации связей между узлами/процессами на базе открытых стандартов и/или протоколов

Допустим, что у нас есть десяток-полтора узлов внутри локальной сети. На каждом узле работает свой набор прикладных процессов. Разных процессов. Процессы должны обмениваться между собой данными. Например, процесс A должен отослать сообщение процессу B, процесс B -- процессу C, процесс C -- процессу D, процесс D -- процессам A и B. При этом процессы A и B могут работать на одном узле, процессы C и D -- на разных узлах. Взаимодействие может быть как в режиме fire-and-forget, так и в режиме request-reply. Но больше, все-таки, в режиме fire-and-forget. Поток сообщений более-менее приличный: от нескольких десятков тысяч сообщений, до сотни тысяч. Размер сообщений относительно небольшой, порядка 1.5-2 килобайт.

Сходу приходит в голову, что организовать такое взаимодействие можно на базе какого-то MQ-брокера. Т.е. на каком-то узле поднимается MQ-шный брокер, к которому подключаются все остальные, все процессы подписываются на соответствующие топики. При этом процессу A совершенно не нужно знать, где именно работает процесс B. Процесс A просто отсылает свое сообщение брокеру, а процесс B получает сообщения от брокера.

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

Поэтому можно смотреть и в сторону peer-to-peer взаимодействия. Например, на базе модного нынче REST-а. Получится, что в каждом процессе открывается HTTP-вход, на который и приходят REST-запросы. Процесс A делает REST-запрос к процессу B, процесс B делает запрос к процессу C и т.д. Все знают URL-ы процессов, с которыми взаимодействуют и могут сделать запрос напрямую. Что хорошо.

Проблема с REST-ом в том, что он отлично ложится на взаимодействие request-reply. А вот для fire-and-forget уже не так хорошо: зачем, спрашивается, делать отдельный HTTP POST, пусть даже и по keep-alive соединению, если ответ нам все равно не нужен (как и подтверждение доставки)? Понятное дело, что современные HTTP-сервера способны обрабатывать сотни тысяч запросов на одном ядре. Но все-таки...

Как я понимаю, под такие задачи хорошо ложится, например, система взаимодействия процессов в Erlang-е. Там процесс A знает PID процесса B и просто отсылает B сообщения. Если A и B оказались на одной ноде в рамках одной Erlang VM, то для доставки сообщения вообще никаких внешних IPC не будет задействовано. Проблема в том, что это Erlang-овая кухня, которая не подойдет, если нужно организовать интероперабильность процессов, реализованных на разных языках программирования (например, C++, Java, Python).

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

PS. Вопрос вызван не какой-то конкретной задачей, а попыткой осмыслить подходы к реализации нескольких систем, о которых довелось узнать.

[prog.c++] Разбор asfikon's "C vs C++". Часть 3.

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