[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".