Везет на странности
В 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
no subject
no subject
no subject
>для реализации poll поверх IOCP используются недокументированные функции afd.sys
Мне впоминаются строки известной песни:
Шанкр вместе с гонореей
Тоже выдумал еврей.
Только зачем? Вот не понятно!
no subject
С учетом того, что информации про эти функции - ровно две страницы в гугле.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Аналогом poll в винде является именно IOCP. А эмуляция poll на select'е образца 1983 года будет весьма медленной, и по умолчанию не поддерживает больше 64 сокетов. После использования такого вот "кроссплатформенного" подхода господа линуксоиды начнут кричать про "тормозную винду".
no subject
no subject
no subject
no subject
Обратная сторона такой преемственности — это геморройность обновлений, да. Каждое обновление сопровождается хитрым логическим выражением, проверяющим версии DLL, записи в реестре, подключённое железо и ещё всякое такое.
Сделать так, как в Gentoo, не получится. Это, скорее, надо функционально–реактивное программирование применить, чтобы ускорить процесс. То есть, конфигурация компьютера — это поведение (то есть, функционально–реактивное значение). Конфигурация OS — это результат функции от конфигурации компьютера. И конфигурация компьютера, и функция от этой конфигурации могут инкрементально меняться со временем, вызывая реакции, по итогам которых результат перевычисляется с минимально требуемыми перевычислениями. Я пока не вижу, чтобы ФРП добралось до пакетных менеджеров, так что имеем то, что имеем.