[prog.c++] Добавили в RESTinio возможность получить remote_endpoint

Мы выпустили небольшое обновление для RESTinio, в котором добавили возможность получить remote_endpoint для HTTP-запроса или WS-соединения. В классы request_t и websocket::basic::ws_t добавлен метод remote_endpoint(), возвращающий ссылку на значение типа asio::ip::tcp::endpoint.

Свежую версию, 0.4.8.5, в настоящее время можно взять с BitBucket или GitHub. Обновление пакетов для vcpkg и conan-а последует несколько позднее.

В принципе, появление remote_endpoint() рассматривается как первый шаг к тому, чтобы добавить в RESTinio возможность блокировки нежелательных подключений. Например, приложение может контролировать активность клиентских подключений и если видит что-то подозрительное (скажем, большое количество однотипных запросов или запросов с некорректными параметрами от одного узла), то приложение может на какое-то время прекратить обработку подключений от этого узла. Ну, или в совсем простом варианте -- тупо поддержать что-то вроде black/white lists.

Но это большой кусок работы, в котором пока много чего непонятного. Так что пока ограничились добавлением remote_endpoint(), а остальное будем выкладывать по мере готовности. Но если кому-то хотелось бы видеть подобную функциональность в RESTinio, то дайте знать. Возможность пообсуждать новую функциональность предметно пойдет на пользу всем сторонам.

Пару слов о состоянии RESTinio. У нас сейчас нет достаточных ресурсов для активной работы над RESTinio, поэтому разработка новой функциональности несколько заморожена. Но если вы встречаетесь с какими-то косяками или непонятными моментами в работе RESTinio, то дайте нам знать. Мы стараемся с такими случаями разбираться максимально оперативно.

Так же, если вы хотите что-то увидеть в RESTinio, то дайте нам знать. Хотелки пользователей упрощают нам планирование наших работ.

[prog] Любопытный момент при реализации решения "обедающих философов" с использованием очереди "обиженных" философов

Тема "обедающих философов" продолжает набирает плюсики в разных соцсетях, что означает необходимость выполнить свое обещание и представить решение на базе акторов с описанием. Над чем, собственно, сейчас и работаю.

Что пока удивило больше всего. Про саму задачу "обедающих философов" я знаю уже лет 25, если не больше. Даже помню, кто из преподавателей в нашем универе нам про нее на лекции впервые рассказывал. И помню, что за это время раза два мне приходилось ее реализовывать в, так скажем, иллюстративном варианте. Т.е. не находить оптимальное решение, а просто делать реализацию, которая лишена хотя бы проблемы дедлоков. А вот решать ее всерьез, чтобы устранить и дедлоки и голодания, да еще в строгом соответствии с исходной формулировкой... Вот этого не приходилось делать.

Сейчас по ходу написания реализации, которая использует арбитра и очередь "обиженных" философов (т.е. философов, которым вилка не досталась и они не смогли поесть), столкнулся с любопытным и изначально не очевидным для меня моментом.

В исходной статье, которая стала толчком для всей этой истории, реализация с арбитром и очередью называется WaiterFair (исходники этой реализации здесь). Хотя в этой реализации есть ошибка и проверяется там наличие только соседа справа.

Итак, в чем суть этой очереди и почему там нельзя проверять наличие обоих соседей?

[prog] И еще раз об обозримости task-based подхода

В докладе "Actors vs CSP vs Tasks..." на C++ CoreHard Autumn 2018 (видео тут, текстовая версия тут) я сказал, что когда код пишется с использованием task-based подхода, то обозримость у этого кода получается так себе. А несколько дней назад на Reddit-е всплыла ссылка на статью под названием "Modern dining philosophers". В которой как раз демонстрируется несколько подходов к решению известной задачи "обедающие философы". Но все эти подходы используют task-и.

Желающим проверить тезис о не очень хорошей обозримости task-based подхода очень рекомендую с данной статьей ознакомится. И составить собственное впечатление о том, насколько просто вам было разобраться с тем, на каком контексте каждая сущность выполняет свою работу. И насколько просто вам было убедиться в отсутствии проблем, связанных с многопоточностью.

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

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

PS. Я думаю написать статью с разбором решения этой же задачи на базе SObjectizer-овских агентов. Кому интересно подобное "сравнение" (хотя это не будет чистой воды сравнением), не пожалейте времени поставить плюсадынку или лайк. Чем больше оных наберется, тем быстрее появится моя статья.