[prog.c++.sobjectizer] Реализация дедлайнов для сообщений своими руками

Около месяца назад появилась идея добавить в SObjectizer механизм ограничения времени жизни сообщений. В процессе обдумывания способов ее реализации было рассмотрено несколько подходов, ни один из которых не показался настолько удобным, чтобы захотелось воплотить его в коде, а затем сопровождать и поддерживать эту функциональность в будущих версиях SObjectizer.

В связи с этим возник резонный вопрос: если все так туго идет, то туда ли вообще попали? И нужно ли продолжать? Может быть такого же эффекта достичь уже имеющимися средствами?

Для одного из описанных месяц назад сценариев, похоже, можно обойтись тем, что уже есть в SObjectizer.

Речь идет о случае, когда агент S отсылает сообщения-запросы агенту R, которые должны быть обработаны за указанное время. А если они не обработаны, то должны быть проигнорированы. Такого эффекта вполне можно достичь, не модифицируя ядро SObjectizer. Как минимум двумя простыми способами.

[prog.c++] И еще про короутины. User-Mode Scheduling в 64-битовых Window 7 и выше.

Продолжение темы (часть 1, часть 2, часть 3, часть 4).

К своему стыду не знал, что в Windows 7 появилась весьма интересная штука: User-Mode Scheduling. Между тем, для реализации акторов в виде последовательных функций, а не в виде конечных автоматов, это очень интересная штука.

[prog.c++] Продолжение про короутины. Доклад "Coroutines, Fibers and Threads, Oh My!"

Продолжение темы (часть 1, часть 2, часть 3).

Вот доклад "Coroutines, Fibers and Threads, Oh My!" с конференции C++Now 2014 (под видео есть ссылка на PDF-ку со слайдами доклада).

Помню, что эту PDF-ку уже смотрел в августе/сентябре, наткнулся на нее когда искал информацию об использовании короутин вместе с Asio. Тогда в презентации меня интересовала только та часть, которая касалась Asio. Поэтому в первом примере с XML SAX-парсером я не разбирался. Сейчас разобрался. Кое-что про короутины стало понятнее. Так что, если у кого-то, как у меня, есть проблемы с тем, чтобы понять где, как и с чем употреблять короутины, рекомендую покурить именно этот пример с XML SAX.

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

[management] Цитата из книги "В поисках совершенство": одиннадцатая заповедь компании 3M

Еще одна замечательная цитата из книги "В поисках совершенства":

Если вы хотите понять культуру, которая стимулирует предпринимательскую деятельность в компании 3M, лучше всего начинать с уяснения ее системы ценностей и, в частности, с ее "одиннадцатой заповеди". Эта заповедь гласит "Не убий идею нового продукта"... Как замечает один из исследователей 3M, деятельность большинства крупных корпораций, как правило, противоречит это одиннадцатой заповеди. Кроме того, добавляет он, "если вы хотите остановить какой-либо проект, целью которого является разработка нового продукта, бремя доказательства целесообразности такого решения возлагается на того, кто хочет остановить проект, а не на того, кто предлагает этот проект. Когда вы подменяете необходимость доказательства того, что соответствующая идея хороша, необходимостью доказательства того, что эта идея плоха, вы в корне меняете саму обстановку, атмосферу в компании в том, что касается поддержки людей, обладающих предпринимательской жилкой".

[prog.c++.thoughts] Продолжение размышлений на тему короутин в C++ приложениях

Очередная заметка в серии про короутины и await с попыткой понять, к чему все это идет. Первая заметка серии здесь, вторая здесь. Так же читателям может быть интересна более ранняя заметка "FiniteStateMachines vs Coroutines".

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

[prog.flame] IBM пора раскапывать OS/2 Warp? ;)

Наткнулся вот на эту беседу, а там вот на это:

Просто мы столкнулись с тем, что даже в виде Erlang on Xen виртуальная машина Erlang-а — это достаточно серьезная штука. Ей нужно 25 Мб памяти, ей нужно 3 Мб диска, сам image занимает — виртуальная машина со всеми приложениями там, допустим, 8 Мб, какой-то web-сайт средненький, web-магазин будет занимать где-то 10 Мб. Ну, и памяти нужно минимум для старта 20-30.

Сразу вспомнилась старая-добрая 3-я полуось, известная так же как OS/2 Warp, от 1994-го года. Полноценная, надо сказать, 32-х битовая ОС, с отличной поддержкой вытесняющей многозадачности (Windows она тогда заруливала влет). И вот эта самая OS/2 3.0 с текстовой оболочкой TShell вместо графического Presentation Manager-а на не очень шустром 386-ом с 4MiB памяти спокойно поддерживала одновременную работу нескольких приложений и быстрое переключение между ними, причем одним из приложений был Doom II.

Ну, собственно, вдумайтесь. На современных топовых смартфонах куча работающих на частоте свыше гигагерца ядер, несколько гигабайт памяти, при этом едва-едва достигая более-менее приемлемой для пользователя отзывчивости... Какой-то, блин, долбанной виртуальной машине какого-то там Erlang-а нужно 25Mb оперативки... Тогда как нормальная ОС, сделанная людьми, которые знали, что и как нужно делать, спокойно работала на 20MHz-процессоре и 4MiB RAM.

Так может не зря IBM не спешила раскрывать исходники OS/2? Может сейчас, когда народ озадачился тем, чтобы создавать на одном физическом сервере все больше и больше виртуальных машин с полноценной ОС внутри, попробовать реанимировать OS/2? Может вместо того, чтобы создавать окружения, где прикладное приложение работает вообще без ОС, лучше вспомнить про действительно хорошие, пусть старые и подзабытые ОС, которые отлично работали на совершенно дохлых, по нынешним временам, машинах?

PS. Прошу не воспринимать это слишком всерьез :) Но реально забавно читать про попытки уместиться в 20MiB RAM, когда для нас в свое время это была какая-то сказочная роскошь.

[management] Цитата из книги "В поисках совершенства": система преодоления беспорядка

Просто шикарная история про противопоставление стремления к порядку и творческого хаоса:

История успеха IBM 360 -- яркий пример невиданного успеха в американском бизнесе, однако процесс разработки этого изделия был довольно-таки неряшливым. Еще до его окончания председатель совета директоров Томас Уотсон-старший попросил вице-президента компании Френка Кери "разработать систему, которая застраховала бы нас от повторения подобного рода проблем". Кери сделал то, что ему сказали. Несколько лет спустя, когда сам Кери стал председателем, он первым делом избавился от сложнейшей структуры разработки изделий, которую внедрил по указанию Уотсона. "Мистер Уотсон был прав, -- соглашался Кери, -- она (структура разработки изделия) предотвратит повторение беспорядка, сопровождавшего разработку IBM 360. К сожалению, она будет так же гарантией того, что мы никогда не изобретем ничего подобного IBM 360".

[prog.c++.thoughts] У короутин и механизма await-а есть таки уникальные достоинства

Нижеследующий текст -- это результат раздумий на тему недавнего поста про потенциально возможный await в C++17. Если кому-то из читателей интересен небольшой поток сознания о том, в каком случае await с короутинами однозначно заруливает message-passing и finite-state machenes, милости прошу под кат.

[management] Цитата из книги "В поисках совершенства": коротко о главном

Просто шикарные несколько предложений, характеризующих способ действия успешных компаний:

...передовые компании прежде всего хорошо усвоили азы: готовые методики не могут заменить рассуждения, интеллект не заменит мудрость, анализ не должен препятствовать деятельности. Эти компании, скорее, прилагали большие усилия для того, чтобы сохранить простоту в сложном мире. Они старались и боролись за качество. Они дорожили своими клиентами, прислушивались к подчиненным и воспринимали их всерьез и не ограничивали новаторства. Они допускали некоторую степень хаоса, чтобы взамен получить скорость и наладить постоянное экспериментирование.

[prog.c++17] Это только мне сложно воспринимать более-менее реальный код с await?

В C++17 предлагают добавить еще средств для поддержки асинхронности. Например, в виде ключевого слова await. На isocpp.org недавно проскочила ссылка на статью с демонстрацией якобы удобства await в более-менее приближенном к реальности коде из области игростроения: Await, coroutines, what could that bring for game development. Там же, рядом со статьей, есть код демонстрационного проекта, можно скачать посмотреть повнимательнее.

Так вот, толи лыжи реально не едут, толи я идиот, но что-то при попытке разобраться в деталях, что и как будет работать, какой-то простоты при использовании await и короутин заметить не удалось :(

[management.book] Впечатления о книге "В поисках совершенства. Уроки самых успешных компаний Америки"

Если в двух словах, то книга из категории "must read". Только обязательно нужно затем прочитать статью одного из авторов, Тома Питерса, приуроченную к двадцатилетию книги: "Tom Peters's True Confessions" (часть 1, часть 2).

[халтура] Таки подробнее про ролик PayUP-а

Накануне Нового Года не было большого желания портить людям праздник и заострять внимание на качестве "продукта", т.е. рекламного ролика сервиса PayUP. Но увиденное оставило такое неизгладимое впечатление, что полностью отказаться от комментариев оказалось выше моих сил :)

[management] Тотальный контроль убивает здоровые инициативы снизу

Ниже приведена большая и, как мне представляется, очень показательная цитата из книги "В поисках совершенства. Уроки самых успешных компаний Америки". Рассказанная в ней история хороша сама по себе. Но еще круче было другое: стоило по ходу чтения подумать о тотальном контроле, как тут же, буквально через несколько строк получил яркое подтверждение своей мысли.

Итак, начало истории: