tgoop.com/reverse13/671
Create:
Last Update:
Last Update:
Опять давно не писал...
В плюсах есть 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
:BY Loser story
Share with your friend now:
tgoop.com/reverse13/671