суббота, 31 декабря 2016 г.

[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). Редкой укуренности фильм. И если с участием Николаса Кейджа все понятно, он сейчас во всяком дерьме снимается, то вот как туда занесло Уиллема Дефо -- вот это загадка.

понедельник, 26 декабря 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 диспетчеров. Не просто, но вроде логично.


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

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