суббота, 31 октября 2015 г.

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

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

[prog.c++11] Автоматический возврат объекта в пул за счет кастомного deleter-а и стандартных умных указателей

Никогда раньше с таким применением умных указателей не сталкивался, но забавная тема на LOR-е показала, что стандартные умные указатели легко могут использоваться не только для уничтожения объекта, но и для возврата объекта в тот пул объектов, из которого объект был взят.

Суть проблемы: есть пул объектов типа T, объект берется на какое-то время из пула, а когда объект становится больше не нужен, он должен вернуться обратно в пул. Причем пулов в программе может быть много. А код, который использует взятый из пула объект, ничего про пул не знает, но объект должен вернуться в тот пул, которому принадлежит. При этом гарантируется, что пулы живут долго, так что о той проблеме, что пул будет разрушен раньше, чем в него вернут все взятые ранее объекты, можно не беспокоится.

среда, 28 октября 2015 г.

[prog.c++.bugs] Как я одну серьезную ошибку профукал

Вчера вечером, когда подготовка к релизу очередной версии SObjectizer-а не просто вышла на финишную прямую, а уже почти подошла к самой финишной черте, всплыла серьезная ошибка. Суть в том, что у каждого агента есть свой собственный direct_mbox. Этот direct_mbox представляет из себя что-то вроде хитрого прокси через который сообщения доставляются агенту напрямую. Важнейшим свойством direct_mbox-а должна была быть возможность корректно обрабатывать ситуацию, когда сообщение отсылается агенту, а агента уже и нет, он закончил свою работу и был уничтожен ранее. Так вот внезапно оказалось, что это свойство не работает! Т.е. в direct_mbox-е остается повисший указатель, при обращении к которому может происходить все, что угодно: от зависаний до крахов приложения.

Очевидно, что в процессе переделок реализации direct_mbox-ов и агентов, коих было не так уж и мало, вышеозначенное важнейшее свойство было утеряно. Но почему это не было отловлено ни одним из тестов (коих сейчас уже больше 170)? И вот тут-то выяснилась интересная история :)

вторник, 27 октября 2015 г.

[comp] Обсуждением Intel Stick навеяло...

Глянул краем глаза RSDN-овское обсуждение такой прикольной штуки, как Intel Stick. Почему-то вспомнились две вещи.

Когда-то давным давно, лет 15 назад, был опыт защиты программы от копирования посредством хардварного ключа Aladdin, цеплявшегося к одному из портов компьютера. Сейчас штуки вроде Intel Stick-а могут существенно упростить поставку программно-аппаратных комплексов заказчику, что называется, "под ключ". Какое-нибудь специализированное ПО для кассовых терминалов или рабочих мест банковских РКЦ. Особенно если в Stick-ах будет какое-нибудь встроенное хранилище криптографических ключей (какой-то аналог HSM-ов), то вообще круто.

Так же давно, лет 12 назад, а может и больше, сильное впечатление на меня произвела статья о том, как Google подходил к выбору компьютеров для своих дата-центров. Вместо ТОП-овых серверов они закупали дешевые морально устаревшие персоналки (помнится тогда писали о Pentium III, хотя у всех уже были машины с процессорами следующего поколения). Производительности Google достигал за счет распараллеливания вычислений на большое количество узлов, а не за счет мощности отдельных узлов кластера. Если попытаться сейчас представить Intel Stick-и в роли тогдашних Pentium III в Google, то рынок серверного хозяйства может ждать больших перемен. И, может быть, что-то интересно ждет и системы виртуализации, вокруг которых было много движухи в последние время...

воскресенье, 25 октября 2015 г.

[prog.d.flame] Куда может завести отсутствие чувства меры и чувства стиля

К счастью, очень давно не смотрел на язык программирования D. А тут в рамках LOR-овского флейма потребовалось выяснить, какие аналоги C++ных умных указателей есть в D. И увидел прекрасный прототип метода refCountedPayload() в шаблоне std.typecons.RefCounted:

inout nothrow @property ref @safe inout(T) refCountedPayload() return;

Внимание, вопрос: при чем здесь тот самый Александреску? ;)