Везет на странности
В libuv (сишная либа для async io, используется в node.js, rust(вроде бы) и прочем таком) для реализации poll поверх IOCP используются недокументированные функции afd.sys - фактически, реверс-инжинеренный кусок кода из winsock.dll:
https://github.com/libuv/libuv/blob/v1.x/src/win/winsock.c#L477
https://github.com/piscisaureus/epoll_windows/blob/master/src/epoll.c#L721
http://x64blog.name/1306870455
Конечно же, тесты этого дела странным образом падают на 2003 винде.
Не то, чтобы мне сильно был нужен epoll на винде, да интегрированный в event loop этой либы, но безумные решения, попадающиеся под руки каждый день, задолбали уже.
https://github.com/libuv/libuv/blob/v1.x/src/win/winsock.c#L477
https://github.com/piscisaureus/epoll_windows/blob/master/src/epoll.c#L721
http://x64blog.name/1306870455
Конечно же, тесты этого дела странным образом падают на 2003 винде.
Не то, чтобы мне сильно был нужен epoll на винде, да интегрированный в event loop этой либы, но безумные решения, попадающиеся под руки каждый день, задолбали уже.
no subject
Обратная сторона такой преемственности — это геморройность обновлений, да. Каждое обновление сопровождается хитрым логическим выражением, проверяющим версии DLL, записи в реестре, подключённое железо и ещё всякое такое.
Сделать так, как в Gentoo, не получится. Это, скорее, надо функционально–реактивное программирование применить, чтобы ускорить процесс. То есть, конфигурация компьютера — это поведение (то есть, функционально–реактивное значение). Конфигурация OS — это результат функции от конфигурации компьютера. И конфигурация компьютера, и функция от этой конфигурации могут инкрементально меняться со временем, вызывая реакции, по итогам которых результат перевычисляется с минимально требуемыми перевычислениями. Я пока не вижу, чтобы ФРП добралось до пакетных менеджеров, так что имеем то, что имеем.