TGViewer
Loser story Loser story @reverse13 · 946 subscribers
Post #671 1.01K
Опять давно не писал...

В плюсах есть built-in T* operator+(T*), он как и некоторые другие built-in операторы нужен в основном для разрешения перегрузок, нам же интересно другое его немного нестандартное применение:
auto lambda = [] {};
auto func = +[] {};
using ptr = void(*)();
static_assert(std::is_same_v<ptr, decltype(func)> && !std::is_same_v<decltype(func), decltype(lambda)>);

Это работает, потому что лямбда с пустым захватом умеет неявно каститься в указатель на функцию, в итоге мы вызываем этот каст с помощью operator+.
Мне недавно это пригодилось, чтобы написать код аккуратнее код, который работает с несколькими разными лямбдами без захвата, как с переменными одного типа.


А теперь резкий переход, cегодня вспоминал io_uring [1], по работе, и понял, что ни разу не писал в канал про эту абстракцию, которая мне очень нравится.
Ниже речь пойдет только про Linux.

В Linux до относитель недавнего времени (5.1) существовало по сути два способа взаимодействия с файловой системой:

Способные блокировать поток, сисколы (read, write, etc), простое, но неэффективное API прямиком из 70ых (в golang есть интересный хак, когда вы делаете блокирующий сисколл [2], поток тредпула (m), исполняющий горутину, отдает свою очередь горутин (p) шедулеру, и соотвественно другие потоки без очереди могут ее захватить). В плюсах же чаще для файлового IO просто делают отдельный тредпул. Главная проблема этого подхода он не масштабируется, так как мы добавляем порядок, синхронизацию, там где оно не нужно.

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

В ядре 5.1 появилось новое API — io_uring.

Некоторая предыстория моего знакомства с этим API:

Года так 3 назад, я задавался вопросом, а можно ли как-то сделать асинхронный fsync append-only файла. Задача была в том, чтобы по событию синхронизировать файл в который писались данные, при этом отсутствовал внешний наблюдатель (то есть смысла ожидать fsync не было, хотелось как бы попросить OS: пожалуйста, если можешь синкани состояние этого файла как можно скорее).

И тогда ответом было, что такого способа нет (может прийти идея создавать поток на каждый fsync, но даже не обращая внимания на то, что это дорого, в этом нет смысла, так как другие блокирующие операции, записи, блокируются и ждут когда мы доделаем fsync), нашел я тогда только патч в ядро линукса, который вроде бы делал то что я хотел.
Позже его приняли, и разобравшись в том, что это такое, я однозначно могу сказать, что на сегодняшний день эта задача прекрасно решается с помощью io_uring:
More from @reverse13
  1. Jul 29, 2026Вообще мы тут сделали end-to-end search/analytics benchmarks на 1e9 otel logs Планируем ту…
  2. Mar 19, 2026Последние пару месяцев смотрел и правил перф серчевого движка и в общем у нас наконец-то е…
  3. Dec 23, 2025Мы тут написали небольшой пост про свой iobuf который юзаем для реализации postgres проток…
  4. Dec 2, 2025Привет, мы частично заопенсорсили текущий код нашего проекта -- SereneDB. Это оказалось тя…
  5. Sep 28, 2025Вообще вот странная штука, больших проектов на C++, C, Rust которые делают базы данных или…
  6. Aug 30, 2025Решил почитать перед сном коммиты в llvm libc++, а то там llvm 21 вышел, думаю может обнов…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →