Ретраи с exponential backoff c jitter в userver работают из коробки для клиентов (пример). Retry budget для клиентов сейчас не доступен в опенсорс, но есть возможность вручную выставлять на стороне сервера ограничение на RPS на "ручку"; и ограничение RPS на сервер целиком выставляется автоматически логикой Congestion Control. Плюс во все компоненты (сервер, клиенты, базы данных) проинтегрирован Deadline Propagation

Так что сервис на userver убить ретраями просто так не получится.

В добавок, сейчас есть Congestion Control для Монги (и скоро появится для PostgreSql!). Так что есть автоматика, которая осознаёт что база данных чувствует себя плохо даже без ретраев, и помогает выйти ей из MFS.

P.S.: Постараемся вынести retry budget для клиентов в опенсорс версию, чтобы userver понежнее относился к сервисам-клиентам

Всё верно, нельзя пользоваться никакими сторонними блокирующими примитивами синхронизации и блокирующими операциями из основного таск процессора (тред пула).

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

Делается это легко - передаёте нужный таск процессор в utils::Async

P.S.: мы распишем этот момент в документации поподробнее

Чтобы начать что-то многопоточно считать обычно используется utils::Async или AsyncNoSpan, множество задач дожидаются через GetAll или WaitAny. Для более сложных синхронизаций между задачами, созданными через Async*, есть целый набор примитивов синхронизации и многопоточных контейнеров.

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

Да, применим. У нас многие сервисы именно с таким профилем

Не в приоритете :(

Но если кто-то принесёт PR с поддержкой и тестами, мы с радостью поревьюим, вмержим, а автора поблагодарим!

Вот например код:

const auto& data = cache.Get()[some_user];
foo(data);

Кажется что всё ОК, и тесты вам покажут что всё ОК. Однако, гард защищающий содержимое от конкурентных обновлений, будет уничтожен на первой строчке, а значит что data потенциально может обновиться в фоне и ссылка начнёт указывать на невалидные данные или недоступную память. И такую проблему фиг осознаешь!

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

const auto snapshot = cache.Get();
const auto& data = snapshot[some_user];
foo(data);

Для предотвращения подобных ситуаций есть класс SharedReadablePtr, многие RCU-подобные классы устроены так же (например rcu::ReadablePtr).

Ага, есть у нас такие планы. Ну и документацию с примерами улучшить в этом месте тоже хотим

Спасибо!

А что такое cci ?

В изначальном предложении была возможность создавать разные hazard pointer domain. Однако в прототипе умудрились так соптимизировать, что разные домены уже не давали щутимого улучшения производительности, и их отложили "на потом"

Концепты приняли в C++20. А вот контракты активно обсуждаются

Планы на корутины амбициозные, планируется втащить всё что может понадобится при разработке корутиновых фреймворков. В ближайших планах: ленивая таска (функция сразу приостанавливается, пока не позовут co_await)

Сделали чтобы старый код не сломался. Пока переменная _ одна в области видимости, она работает как совсем обычная пременная, и к ней можно обращаться:

{
auto _ = foo();
std::cout << _;  // OK
  {
    auto _ = bar();
    std::cout << _;  // OK, предупредит о shadowing variable
  }
}

Порой приносят новые, порой убирают старые. В этот раз убрали пачку UB из лексера

На самом деле так и планируется: рефлексия хочет сделать consteval переменную, которая умеет хранить тип. И тогда можно сделать контейнер из таких переменнх и прогнать его через ranges. Получится как в вашем примере, и кажется даже decltype писать не надо будет

В “Concerrency in action“ было создание своего наколеночного hazard pointer. Если хочется прям оптимальной имплементации, можно повкуривать в исходники libcds или folly

Над корутинами работа идёт, но не так быстро как хотелось бы. Надеюсь что принятие executors подтолкнёт развитие как корутин, так и Networking

Обычно фичи из C в C++ бекпортируются очень оперативно. Но proposal именно на эти атрибуты пока не рассматривался в комитете.

Да, есть своя прелесть в таком синтаксисе. Но тогда плохо сочетается с structured binding

Ну можно вот так, даже короче получается:

{
    std::scoped_lock _{my_mutex};
    // critical section
}

О каких именно предложениях вы говорите?