Человек человеку волк (Dog Eat Dog, 2016). Редкой укуренности фильм. И если с участием Николаса Кейджа все понятно, он сейчас во всяком дерьме снимается, то вот как туда занесло Уиллема Дефо -- вот это загадка.
Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
суббота, 31 декабря 2016 г.
[life.cinema] Очередной кинообзор (2016/12)
Человек человеку волк (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 диспетчеров. Не просто, но вроде логично.
Получается, что на этот вопрос есть две точки зрения. Хотя мне кажется, что одна из них неправильная. Поэтому прошу читателей помочь определиться с тем, какая именно неправильная.
Возможно, я что-то сумбурно и непонятно описал. Поэтому уточняющие вопросы приветствуются -- с удовольствием разверну тему более подробно.