Issue #93 remove libc compat from contrib

[tsayukov]

Issue #93

Задача в том, чтобы отказаться от использования libc_compat.

Части libc_compat, которые больше не используются в ydb-cpp-sdk и которые можно спокойно убрать:

• [x] getservbyname/: функция getservbyname и все её помощники. Ранее она была нужна, потому что у llvm msan до сих пор нет interceptor-обёртки для неё (чтобы убедиться в этом, можно написать простой main c ней, скомпилировать с -fsanitize=memory и через readelf -Ws и grep посмотреть таблицу символов), и включение санитайзера могло выдавать ложноположительные результаты.
• [x] include/ifaddrs/. Ранее ifaddrs.h добавлялся для Андроида с API level <24; сейчас это не целевая платформа, а также в текущей либе убрали соответствующий c-файл, так что можно не обращать на хедер внимания. Все остальные #include <ifaddrs.h> в ydb-cpp-sdk включаются через #if только для Unix-like систем и ссылаются на glibc. Для других платформ подключаются системные хедеры этих платформ с аналогичным функционалом.
• [x] include/readpassphrase/.
• [x] random/: функции getentropy и getrandom. Ранее были нужны из-за их отсутствия в более старых версиях glibc.
• [x] ubuntu_14/. Ранее файлы из этой папки нужны были, чтобы на старых версиях Ubuntu ниже 14 находились нужные символы, которых ещё не было в libc.

Из остальных хедеров, не считая include/windows/sys/, в ydb-cpp-sdk подключается только contrib/libs/libc_compat/string.h. В нём нас интересуют только функции stricmp, strnicmp, strlcpy, strlcat и strlwr.

• [x] Скопировать реализации strlcpy, strlcat и strlwr в include/ydb-cpp-sdk/library/string_utils/helpers/helpers.h как size_t Strlcpy(char*, const char*, size_t), size_t Strlcat(char*, const char*, size_t), char* ToLower(char*). Далее заменить все вызовы на вызовы этих функций.
• [x] В include/ydb-cpp-sdk/util/system/compat.h определить макросы stricmp и strnicmp, которые в зависимости от платформы будут подставлять соответствующие функции из системного хедера strings.h или string.h.
• [x] Дополнительно:
  • [x] В src/library/case_insensitive_string/case_insensitive_char_traits.h привести трейт в соответствии с требованиями. Добавить юнит-тесты.

include/windows/sys/ содержит два хедера: queue.h и uio.h. Первый, sys/queue.h больше не включается в ydb-cpp-sdk. Второй sys/uio.h (в нём нас интересуют две функции: readv и writev) включается при сборке под Windows, таким образом, для остальных систем будет искаться sys/uio.h из glibc, а для Windows выберется хедер в include/windows/sys/, поскольку он добавляется в инклюды libc_compat таргета в cmake. Соответственно, нужно переписать readv и writev в src/library/coroutine/engine/network.cpp и src/util/network/socket.cpp так, чтобы они работали и для Windows, и для платформ с glibc.

Однако, прежде чем перейти к этой задаче, бросается в глаза следующее (и такое встречается не раз):

ssize_t DoReadVector(SOCKET fd, TContIOVector* vec) noexcept {
  return readv(fd, (const iovec*) vec->Parts(), Min(IOV_MAX, (int) vec->Count()));
}

Проблема в том, что каст (забудем пока, что это C-style) из указателя к указателю разных типов по стандарту может привести к UB, когда второй указатель попытаются разыменовать (см. [[basic.lval] par.11], они же Type aliasing). На практике компиляторы в редких случаях эксплуатируют этот UB и скорее всего ничего не взорвётся, но я всё равно бы хотел избегать подобных кастов. Обычно такие штуки решают с помощью std::memcpy, std::bit_cast, а ещё в будущем, когда доимплементируют 23 стандарт, можно будет на месте использовать std::start_lifetime_as без копирований.

Везде, где вызывался readv/writev/sendmsg, наблюдался следующий паттерн:

• передаётся константный массив TPart (аналог std::span) и его длина;
• пытаются вызываться C-шные обёртки над системными вызовами (readv и его друзья), которые читают из или пишут в TPartы из этого массива атомарно или хотя бы асинхронно (как в Windows);
• если не удаётся обработать все байты, копируют массив в буфер;
• считают, сколько байтов ещё осталось, возможно, меняют текущий TPart в буфере (сдвигают его указатель и уменьшают размер), если обработались только первые сколько-то байтов;
• пытаются читать из или писать в оставшиеся байты до первой ошибки;
• возвращают количество обработанных байтов или код ошибки.

У нас уже есть класс-обёртка TContIOVector в util/network/iovec.h. Поэтому я решил добавить в него буфер, но в этом буфере сразу создавать нужные "C-шные" структуры типа iovec или WSABUF, исключая проблему небезопасных кастов. Подсказывает, как копировать (через memcpy или присваиванием), дополнительный трейт TSpanAdapterTraits в качестве шаблонного параметра у TContIOVector, который получился довольно многословным, но в нём я постарался учесть все случаи и сделать максимально обобщённым, а также добавил вспомогательные методы, чтобы можно было бы обращаться к полям "C-шной" структуры в общем случае, заранее не зная, что это за структура. Второй шаблонный параметр у TContIOVector -- это функтор, вызывающий соответствующую C-шную функцию. Причина, по которой я не захотел передавать функтор, например, в метод, -- не хотелось, чтобы один и тот же TContIOVector, изначально предназначенный только для чтения (TPartы, допустим, указывают на константные строки, лежащие в readonly памяти), использовали для записи. Возможно, есть решение получше. У TContIOVector главные методы, которые делают всю работу, -- это TryProcess и TryProcessAllBytes. Соответственно:

• [x] Реализовать TSpanAdapterTraits.
• [x] Реализовать TContIOVectorBase и TContIOVector (базу сделал на случай возможного расширения, например, если захотим мувать TContIOVector-писателя в TContIOVector-читателя).
• [x] Реализовать функторы для readv/writev/sendmsg.
• [x] Поправить места вызова.
• [x] Проверить юнит тесты для сокетов и корутин, исправить ошибки.

Возможно, стоит подумать о том, чтобы заменить TPart (изначально он определён в IOutputStream) на std::span<std::bytes> и std::span<const std::bytes>? TPart плох тем, что он держит в себе const void*, а используют его как для чтения, так и для записи. Моему TSpanAdapterTraits всё равно, с каким span-подобным объектом работать.

Подумал, сильно ли повлияет на производительность сразу выделение буфера (TTempBuf до 64 * 1024 байтов переиспользует массив из готового списка, соответственно он не будет каждый раз просить новую память в куче). С одной стороны, массив span-ов сам по себе не очень большой, копируется моментально. С другой стороны, на очень больших размерах каждый раз будет выделяться память в куче. С третьей стороны, операции ввода-вывода (даже векторные) наверняка перебьют всё остальное.

Вот мой бенчмарк:

Собирался с установленным `libbenchmark-dev`. ```CMake find_package(benchmark REQUIRED) add_executable(iovec_bm iovec_bm.cpp) target_link_libraries(iovec_bm PRIVATE yutil cpp-testing-common benchmark::benchmark_main ) ```

Код:

```C++ #include "network/iovec.h" #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include using namespace NUtils::NIOVector; using TIOVector = TContIOVector; struct RandomWords { static constexpr std::size_t size = 5'000; std::vector words; std::vector parts; public: RandomWords() { constexpr auto max_len = static_cast(std::numeric_limits::max()); std::random_device rd; std::mt19937 gen(rd()); std::uniform_int_distribution lens(0, max_len); std::uniform_int_distribution chars(static_cast('a'), static_cast('z')); const auto get_random_char = [&] { return static_cast(chars(gen)); }; const auto get_random_string_of = [&](std::size_t n) { std::string str; str.reserve(n); std::generate_n(std::back_inserter(str), n, get_random_char); return str; }; const auto get_random_string = [&] { const std::size_t length = lens(gen); return get_random_string_of(length); }; const auto str_to_tpart = [](std::string& str) noexcept { return TPart(str.data(), str.size()); }; words.reserve(size); words.push_back(get_random_string_of(max_len)); words.push_back(get_random_string_of(max_len)); std::generate_n(std::back_inserter(words), size - 2, get_random_string); parts.reserve(size); std::transform(words.begin(), words.end(), std::back_inserter(parts), str_to_tpart); parts[0].len = 0; parts[1].len = max_len; } }; inline auto random_words = RandomWords(); static void Cast(benchmark::State& state) { auto& parts = random_words.parts; const auto size = static_cast(state.range(0)); const auto path = SRC_("test_1"); auto file = std::fopen(path.data(), "w"); const int fd = fileno(file); for (auto _ : state) { parts[0].len += 1; parts[1].len -= 1; auto iov = reinterpret_cast(parts.data()); writev(fd, iov, size); } std::fclose(file); } BENCHMARK(Cast) ->Args({10}) ->Args({100}) ->Args({500}) ->Args({750}) ->Args({1000}) ->Args({2500}) ->Args({4000}) ->Args({5000}); static void PureMemcpy(benchmark::State& state) { auto& parts = random_words.parts; const auto size = static_cast(state.range(0)); TTempBuf heat(1); for (auto _ : state) { parts[0].len += 1; parts[1].len -= 1; TTempBuf buffer(size * sizeof(iovec)); auto iov = new (buffer.Data()) iovec[size]; std::memcpy(iov, parts.data(), size * sizeof(iovec)); benchmark::DoNotOptimize(buffer); } } BENCHMARK(PureMemcpy) ->Args({10}) ->Args({100}) ->Args({500}) ->Args({750}) ->Args({1000}) ->Args({2500}) ->Args({4000}) ->Args({5000}); static void Iovector(benchmark::State& state) { auto& parts = random_words.parts; const auto size = static_cast(state.range(0)); TTempBuf heat(1); const auto path = SRC_("test_2"); auto file = std::fopen(path.data(), "w"); const int fd = fileno(file); for (auto _ : state) { parts[0].len += 1; parts[1].len -= 1; TIOVector iov(parts.data(), size); iov.TryProcessAllBytes(fd); } std::fclose(file); } BENCHMARK(Iovector) ->Args({10}) ->Args({100}) ->Args({500}) ->Args({750}) ->Args({1000}) ->Args({2500}) ->Args({4000}) ->Args({5000}); static void Copy(benchmark::State& state) { auto& parts = random_words.parts; const auto size = static_cast(state.range(0)); TTempBuf heat(1); const auto path = SRC_("test_3"); auto file = std::fopen(path.data(), "w"); const int fd = fileno(file); for (auto _ : state) { parts[0].len += 1; parts[1].len -= 1; TTempBuf buffer(size * sizeof(iovec)); auto iov = new (buffer.Data()) iovec[size]; auto iter = parts.begin(); for (std::size_t i = 0; i < size; ++i, ++iter) { iov[i].iov_base = const_cast(iter->buf); iov[i].iov_len = iter->len; } writev(fd, iov, size); } std::fclose(file); } BENCHMARK(Copy) ->Args({10}) ->Args({100}) ->Args({500}) ->Args({750}) ->Args({1000}) ->Args({2500}) ->Args({4000}) ->Args({5000}); ```

Разные кейсы сравнивал так: ```bash /usr/share/benchmark/compare.py filters ./iovec_bm Cast Iovector ``` Если смотреть по цифрам, то на больших массивах, когда каждый раз в куче начинает выделяться память, видно ощутимое увеличение времени. Но с другой стороны, гугл бенчмарк закрашивает эти цифры красным и говорит, что ему не удалось доказать, что эти кейсы статистически различны. Наверное, разумнее считать, что до серьёзного абьюза кучи всё примерно одинаково со скидкой на ввод/вывод. А дальше непонятно.

Дополнительно util/memory/tempbuf.*:

• [x] Убрать inline у методов с определениями внутри классов, они и так по умолчанию будут inline.
• [x] В макросе TMP_BUF_LEN нет никакой необходимости. Можно перенести его значение в static constexpr поле TTempBuf.
• [ ] Заменить char на std::byte? Поскольку TTempBuf выделяет область в памяти, которую можно использовать, семантически лучше работать с std::byte (или на крайний случай с unsigned char), который как раз и описывает байты в raw memory. Ко всему прочему, в свежем черновике стандарта убрали, что массив charов неявно создаёт объекты в своём хранилище, см. здесь. Пока отказался, потому что другие классы ожидают от TTempBuf charов, и потребуется много чего исправлять, нагромождая reinterpret_castами.
• [x] Заменить C-style касты.
• [x] В классе TPerThreadedBuf добавить явное выравнивание alignas(std::max_­align_­t) полю Data_. Так как класс TTempBuf в зависимости от запрашиваемого размера выделяет память либо в массиве Data_, либо в куче через new, то нужно выбрать такое выравнивание, которое гарантируется в любом контексте (на стеке или в куче), см. [basic.align] p2. Упомянуть в описании класса TTempBuf, что over-aligned типы не поддерживаются.
• [x] Случай, когда TTempBuf выделяет память в куче. Вспомогательный класс TAdditionalStorage (util/memory/addstorage.h) выделяет память следующим образом: сначала идёт блок с внутренностями TTempBuf::TImpl (указатель, размер, смещение), потом корректно выровненный блок с дополнительной информацией (размер нужной нам памяти) и только затем блок с нужной нам памятью. Начало последнего блока выравнивается по alignas(std::size_t), но совсем не факт, что такое выравнивание совпадает с __STDCPP_­DEFAULT_­NEW_­ALIGNMENT__, а ведь new обязано выравнивать память по значению этого макроса, и соответственно наша память, которую потенциально отдаём наружу, должна отвечать таким требования.
  • [x] Завести дополнительный приватный метод InfoPtrOffset, который считает смещение до блока с дополнительной информацией; в методе InfoPtr просто прибавить это смещение.
  • [x] В методе CombinedSizeOfInstanceWithTInfo переиспользовать InfoPtrOffset и весь результат выровнить по __STDCPP_­DEFAULT_­NEW_­ALIGNMENT__ методом AlignUp.

[tsayukov]

• Переместил платформозависимый код в отдельный хедер vectored_io.h.
• Переписал свои тесты в iovec_ut.cpp, чтобы они выглядели более аккуратно, плюс добавил дополнительные проверки.
• Перенёс те тесты, которые потрогал, в tests (в том числе socket_ut.cpp и coroutine_ut.cpp). Остальные тесты из util/network и library/coroutine начну переносить после закрытия этого PR (раз уж я начал, логичнее мне и закончить с #176 и #160?).

[tsayukov]

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

[Gazizonoki]

Я починил сборку в CI, сделай rebase