Как стать автором
Обновить
16
Карма
0
Рейтинг

Пользователь

  • Подписчики 11
  • Подписки 1

Кроссплатформенный многопоточный TCP/IP сервер на C++

Да. Но это ведь ошибка, вы не послали все данные в сеть и вернули, что «всё хорошо».

Кроссплатформенный многопоточный TCP/IP сервер на C++

А если при этом send послал меньше чем просили?

Очереди сообщений в PostgreSQL с использованием PgQ

Понял. Спасибо за статью (и информацию).

Очереди сообщений в PostgreSQL с использованием PgQ

А это тоже самое (вроде как от разработчиков skype) или что-то другое?

www.pgcon.org/2008/schedule/attachments/55_pgq.pdf

Если проект «Театр», используй акторов…

Ну если говорить о «верхнем уровне»(интерфейс оператора, алгоритмы управления), то это два небольших безвентиляторных блока на базе Intel. А по сути «обычные компы», на которые мы установили Linux (ALT Linux).

Какой оверхед по коду?

Да вроде нет «оверхеда» какого-то особого. От использования акторов кода не становится больше, наоборот мне показалось, что логика выражается достаточно лаконично.
По крайней мере с использованием того API который предоставляет sobjectizer.

Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а

Имхо, это одна из вариаций на тему revocable_t

Да похоже что так.

Тогда в продолжение темы, мысль о проблеме revocable_t сообщений с «защитой от переполнения»…

Мне кажется (с одной стороны) revocable_t сообщения в общем случае являются такими же сообщениями как и другие (хоть и могут устаревать уже находясь в очереди на обработку). Поэтому тут нет конфликта. По идее «разработчик» должен настраивать свои лимиты с учётом того, чтобы у него размера очереди хватало и на работу с revocable_t сообщениями
(условно для случая когда они не успевают устареть находять в очереди).

С другой стороны, как вариант, можно было бы добавить ещё одну (настраиваемую) политику обработки переполнения, при которой в случае невозможности поместить новое сообщение в очередь (или канал), происходит её чистка от «устаревших» сообщений. Т.е. прошлись по очереди, если встретили такой вид сообщений, проверили и удалили если устарело. И после этого, если место не освободилось, то реакция «как обычно». Конечно такая чистка может быть «дорогой операцией», но на то это и «отдельная настраиваемая политика обработки».

Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а

Может попробовать зайти с другой стороны? Со стороны обработчика агента?
Т.е. будет специальная функция подписки c проверкой устаревания
и специальный тип сообщений от которых нужно наследоваться
(содержащих в себе всё необходимое для проверки).
Что-то типа

struct my_timer_message: 
  public so_5::lifetime_message_t
{
  ...
}


А подписка:
  st.lifetime_event( &MyAgent::on_timer );

внутри которой «прозрачным образом» пользовательский обработчик будет «обёрнут»
ещё одним предварительным обработчиком с провекой «устаревания»…

Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а

1. Реализация проверки актуальности каждого сообщения перед его обработкой. Позволяет получить отзывные сообщения, но ценой увеличения стоимости обработки любого сообщения. На синтетических бенчмарках это может означать потерю 7-8% производительности. Меня лично такой вариант вполне устроит, но с точки зрения маркетинга такая потеря не есть гуд.


Т.е. я видимо «за этот вариант». С точки зрения «не платить за то, что не используешь», может есть возможность сделать какую-то настройку для диспечера (параметр шаблона или ещё что-то такое)?

Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а

Потенциально, есть еще один вариант, который заточен именно под работу с таймерными сообщениями. ..


Мне кажется этот вариант «тяжелее» проверки флага перед обработкой. Я в целом видел реализацию как ваш старый проверенный способ — «монотонно растущий ID» у сообщений c проверкой перед доставкой.
Мне кажется проверка флага — не настолько дорогая операция, среди
общей массы «проверок» происходящих в среднестатистическом алгоритме.

Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а

Хорошо. Я осознал «высоту полёта и направление»… )
Спасибо.

Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а

РТ — это, так сказать, аспект или, если угодно, cross-cutting concern, и необязательно «пронизывает весь код».


Скорее всего мне не хватает опыта и знаний, посмотреть на проблему таймаутов более масштабно и соответственно решать её на другом уровне.

2. Если уж пошла такая пьянка, то то, что таймаут от одной операции прерывает другую операцию — это баг. А возможность такого развития событий — архитектурный просчет.


Вот это меня заинтересовало. Потому-что мне казалось, что без таймаутов вообще жить невозможно. Т.е. я с ними сталкиваюсь везде, начиная от API ОС и заканчивая алгоритмами в которых существует понятие «отмены операции» или «длительная операция». Поэтому мне очень интересна тема (без шуток), если существуют подходы которые позволяют архитектурно строить систему
условно говоря «без таймаутов». Не могли бы Вы указать какие-то «темы», «источники», «слова» что поискать на эту тему?

Вот как-то так, надеюсь, без обид.

Какие тут обиды. Вы расширяете мне кругозор. Спасибо )

Легко ли добавлять новые фичи в старый фреймворк? Муки выбора на примере развития SObjectizer-а

Речь не обязательно о работе в реальном времени. Речь о любой работе (задаче) связанной с ожиданием (с таймаутами). Не знаю как везде, но как минимум в АСУ, «надёжное программирование» подразумевает, что любая операция должна быть конечной во времени. Поэтому чтобы вы не делали, что-либо включали/запускали
или что-то запрашивали, у Вас обязательно должен быть «защитный таймер» который гарантирует, что вы не застрянете на ожидании ответа «навечно». Т.е. у Вас по сути всегда, для какого-либо действия возникает необходимость произвести действие и засечь таймер (таймаут). И дальше либо «ответ»(обратная связь) придёт о том, что действие выполнено (успешно или нет), либо первее сработает таймер (таймаут) и вы будете выполнять какую-то обработку этой ситуации (например повторите попытку ещё несколько раз)… Тут-то и возникает описанная проблема, что если к Вам пришло вперёд сообщение о, допустим, успешном выполнении операции, то Вам сообщение от таймера уже не нужно. Точнее нужно, чтобы оно уже не приходило. Нужен механизм позволяющий отказаться от ранее заказанного таймера.

А eao197 как раз описал проблему. Что если механизм не гарантирует отказ от таймера (типа он уже в очереди, его оттуда не убрать), то почти гарантировано, что возникнет ситуация, когда Вы решите повторить попытку выполнить команду, засекаете вновь таймер, а сообщение приходит в следующее мгновенье, от старого таймера, потому-что оно уже было в очереди в этот момент…
Т.е. мне кажется, что при активной работе с таймерами (а они нужна практически всегда в реальном асинхронном взаимодействии, т.к. всегда должен быть защитный таймер на любую длительную операцию), отмена таймера (или игнорирование «старых» сообщений от таймеров) очень нужны и важны. И конечно, хочется чтобы это поддерживалось на уровне фреймворка.
Будет ли это механизм с маркированием каждого таймера или же с возможностью вытащить его из очереди на обработку, для меня как пользователя фреймворка не важно. Главное чтобы это было «незаметно» и в идеале не требовало от меня добавлять в свои сообщения доп. поля, по крайней мере явным образом.

Теория и практика бэкапов с Borg

А права на файлы он сохраняет?
А то немного смутило вот это
borg@b3e51b9ed2c2:~$ ll etc/hostname 
-rw-r--r-- 1 borg borg 13 Aug  4 16:27 etc/hostname

Shrimp: масштабируем и раздаем по HTTP картинки на современном C++ посредством ImageMagic++, SObjectizer и RESTinio

Мы у себя в проекте пытаемся использовать SObjectizer. По началу действительно «не привычно», но за день-два написания кода привыкаешь и даже начинает нравиться )

Пишем собственный хитрый thread_pool-диспетчер для SObjectizer-а

Да. «Best practice» хорошая идея. Не хватает.

Почему SQLite не использует Git

Если Вы хотите склонировать репозиторий то «git clone» это и делает.
Никаких --bare Вам не надо.
Не совсем понял что такое у Вас потом «fossil repo open»,
но предполагаю, что это и есть «checkout».
Вообщем мне кажется Вы «немного» преувеличили «сложность и неинтуитивность». Максимум я вижу «я так привык».

Почему SQLite не использует Git

Т.е. по Вашему
fossil clone xxx

это нормально, а
git clone xxx

«сложно и неинтуитивно»?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность