[prog.c++.message-passing] A few words after watching Anthony Williams's "Designing for C++ Concurrency Using Message Passing"

There is Anthony Williams's talk "Designing for C++ Concurrency Using Message Passing" at ACCU 2023. It wasn't an interesting talk for me personally because I didn't find anything new for myself (not surprising, because I have been responsible for the development of a message passing framework for years).

But I would like to add my 2 cents to the topic. I hope my thoughts will help to understand how message passing frameworks can differ from each other. And how such differences can affect the design and writing of software.

---

First of all entities that receive and process messages (let's call them "actors") can be represented as objects with callbacks or as execution threads.

[prog.c++.sobjectizer] Есть идея о том, как пользователь может реализовать собственные очереди сообщений для агентов

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

Конечно же, эти проблемы можно решать по отдельности постепенно развивая SObjectizer и усложняя его ядро.

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

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

Свою текущую идею на этот счет я описал в разделе Discussions на GitHub: https://github.com/Stiffstream/sobjectizer/discussions/64

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

Главный вопрос для меня сейчас -- это интересно ли кому-нибудь данное направление?

Если кому-то интересно, то появляется смысл копать дальше.

Ну а если нет, то подожду удобного случая. Может со временем что-то еще лучше в голову придет.

[career.flame] Рекомендация, которая меня всегда подбешивала...

..."стремись в коллектив, в котором ты будешь худшим".

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

Рекомендацию эту я встречаю уже, если не соврать, лет 15. И каждый раз меня одолевает некоторое недоумение. Чем дальше, тем больше.

В очередной раз у меня подгорело на вот этой иллюстрации, попавшейся в ленте LinkedIn:

Так что не удержусь, позволю себе излить часть желчи и сарказма.

Даже не буду затрагивать вопрос "а что такое быть лучшим?" и пытаться выяснять критерии, которыми следует пользоваться, чтобы определить степень лучшести. Такое ощущение, что люди думают, что выполнение своих обязанностей на работе -- это как участие в спортивных соревнованиях по олимпийской системе с выбыванием. Типа кто победил, тот и лучший.

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

[work] Известный на RSDN-е Ikemefula ищет работу

На когда-то известном в Рунете профильном ресурсе RSDN есть форумчанин Ikemefula (он же Pauel, он же Plutonia Experiment, он же old Dutchman, он же Dutchman). Один из немногих RSDN-еров, который отличался здравыми и логичными суждениями, да еще и записанными нормальным и понятным языком. Признаюсь, мне самому было интересно читать то, что пишет о программировании, хоть не со всем я был согласен. Но, повторюсь, умением связно излагать свое мнение Ikemefula отличался в лучшую сторону и по этому показателю был очевидно круче остальных 99% участников RSDN.

Сейчас ищет работу. Вот его профиль на LinkedIn.

Сам я с Ikemefula не работал и даже никогда не общался с ним вне RSDN, но, имхо, неправильно это когда толковые люди сидят без работы.

[prog.c++] Вот как раз для таких вот задач SObjectizer и бывает полезен

В качестве наглядного примера: свежий вопрос на LOR-е под названием "Приоритетная очередь".

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

PS. Песонаж, который задал этот вопрос, какой-то специфический. Имел опыт общения с ним (сходу вспоминается раз и два), больше не хочу. И пользователей таких для SObjectizer-а тоже лучше бы не надо. Хотя из того, что он понаписывал о своей задаче (решая которую он на LOR-е создает один топик за другим с вопросами, которые, имхо, даже middle-разработчики должны были бы решать самостоятельно), мне кажется, что там SObjectizer (или подобный ему инструмент) был бы именно что в тему.

[prog.c++] Тяжко это, не иметь готовых таймеров под рукой...

Это, фактически, продолжение вот этого поста. Т.е. опять маленькие дифирамбы SObjectizer-у 😉

Привыкаешь к тому, что в SObjectizer-е таймеры из коробки и даже не задумываешься несколько это бывает нужно. А вот когда нет SObjectizer-а, а требуется выполнять какое-то действие раз в секунду или хочется проверить результат какой-то операции через 250ms... И грусть-пичаль 😭

Не, выкрутиться так или иначе можно, спору нет. Но то ж выкручиваться нужно. Придумывать чего-то. А, казалось бы, зачем?

[work.prog.opensource] В каких случаях можно положиться на OpenSource проект (на примере RESTinio)

Простите, меня триггернуло вот на это:

Для тех, кто не хочет переводить текст с картинки в двух словах: на Reddit-е создали тему по поводу инструментов для разработки бек-энда на C++, один из комментаторов сказал, что RESTinio у него в фаворитах, на что другой комментатор привел ссылку на GitHub-овский issue #148, в котором мы в марте 2021-го написали, что дальнейшая разработка RESTinio приостановлена и добавил: "Возможно, мы не должны полагаться на этот проект".

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

Итак, относительно безопасно забесплатно брать в работу тот OpenSource, для которого вы:

• либо можете быстро и безболезненно найти полноценную замену;
• либо можете сами взвалить на себя сопровождение этого проекта (хотя бы на какое-то время).

С первым, пунктом, полагаю, все должно быть очевидно. Грубо говоря, вам нужно работать с регулярными выражениями и вы берете некую библиотеку, которая вам максимально подходит. Если затем выяснится, что библиотека осталась без поддержки, то вы просто берете другую библиотеку, благо их не так уж и мало. Да, что-то где-то придется переписать, но (подозреваю) это будут по большей части косметические изменения, т.к. все они предоставляют плюс-минус одно и то же.

А второй пункт вот о чем: вы взяли чужой проект забесплатно в условиях, когда вам никто и ничего не должен.

Еще раз, акцентирую: вам никто и ничего не должен. Точка.

Кто-то сделал библиотеку X для своих целей, выложил затем это в OpenSource, может быть даже снабдив приличной документацией. И все.

Этот кто-то затем может потерять всякий интерес к дальнейшему развитию проекта, уйти на пенсию или вообще попасть под автобус (а вы думали "bus" в понятии "bus factor" откуда?). И все, вы останетесь с вашим выбором один на один.

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

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

Поэтому, составляя список потенциальных кандидатов не поленитесь заглянуть в исходники. Понимаете ли вы то, что там внутри происходит, нравится ли вам то, что вы видите, готовы ли вы, при необходимости, сопровождать все это сами? Если ответ "Да", то на такой OpenSource проект вы вполне можете положиться.

---

И да, еще подчеркну архиважную вещь, которую, очевидно, далеко не все понимают (особенно молодые да ранние, не нюхавшие еще пороху): авторы OpenSource вам ничего не должны. Люди, открывшие свои исходники, да еще под пермиссивными лицензиями, и так же сделали больше, чем вам кажется. Требовать (подчеркну: требовать) с них чего-то большего у вас нет никаких прав.

Да, многие авторы OpenSource не бросают свои проекты, отвечают на вопросы, реагируют на issue, допиливают код, дополняют документацию. Такое, к счастью, случается повсеместно. Но не нужно думать, что это обязательное приложение к любому OpenSource.

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

К сожалению, мне доводилось встречать среди программистов мнение, что авторы OpenSource должны (должны!!!) сопровождать свой OpenSource. Типа, если ты разместил свою разработку на GitHub, то будь добр, тяни лямку и дальше.

Так вот, это серьезное заблуждение: вам никто и ничего не должен, если вы задарма получаете поддержку от авторов OpenSource, то это просто очень большой бонус, который вы, очевидно, не способны оценить по достоинству.

---

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

Ситуация, когда есть вендор, которому вы платите за его продукт и/или поддержку продукта (пусть даже это полностью OpenSource разработка) принципиально другая. Здесь уже появляются вполне себе оформленные обязательства сторон.

---

PS. Я уже и сам не знаю, как относиться к issue #148.

С одной стороны, все должно быть честно и пользователи нашего OpenSource имеют право знать реальную ситуацию: да, мы активно пилили свои открытые проекты, когда у нас были на это собственные средства и ресурсы, сейчас ситуация изменилась и за свой счет мы уже не можем добавлять новую функциональность в таком же темпе, но если кому-то что-то нужно и этот кто-то готов оплатить доработки, то мы рады будем это сделать.

ИМХО, это должно было быть озвучено, чтобы ни у кого не было лишних иллюзий. Что и было сделано.

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

Я уже слышал советы о том, чтобы переформулировать или даже вообще убрать этот issue. Но пока соблазну не поддался, ибо все должно быть честно и пользователи должны знать реальную ситуацию (далее по тексту...)

Возможно, я в корне не прав, но по другому не могу (пока?). Так что issue 148 останется висеть в своем текущем виде, тем более, что все написанное там сохраняет свою актуальность и сегодня. Upd. После написания этого поста текст issue #148 несколько раз дополнялся.