Windows IO: прерываемость и ожидание готовности

Пытаюсь разобраться с вводом-выводом в (NT-образных) Windows, с желанием добиться следующих результатов:
1. Получить замену полноценному select() (полноценность подразумевает работу с сокетами и всеми возможными несокетами одновременно); 2. получить возможность отменять блокирующую операцию из соседней нити на платформах без CancelIoEx и CancelSynchronousIo (т.е. ранее Висты; вообще целюсь в Win2k и выше — всё, что раньше или вне NT-ветки, не интересует, а всё, что добавлено в Висте — считаю слишком молодым, чтобы на это безусловно опираться). По пункту (2) можно считать, что я контролирую собственно реализацию потенциально-прерываемых read() и write(), а вот относительно открытия файлов — хотелось бы также разбираться с унаследованными хэндлами, не только с собственными.

В связи с этим есть несколько вопросов знатокам внутренностей NT
1. Переключение non-OVERLAPPED дескриптора в FILE_SYNCHRONOUS_IO_ALERT — очевидное решение проблемы прерывания блокирующих операций, но за что-то это решение не любят. Есть ли с ним какие-то реальные проблемы, заметные из userspace? (про проблему с IRQL в ядре/драйверах я знаю, не могу сообразить только, может ли приложение нарваться на её последствия, всего лишь переключив синхронный pipe в ..._IO_ALERT).

2. Есть ли какое-нибудь место, где написано про FSCTL_PIPE_ASSIGN_EVENT? (что оно делает, я знаю — не знаю, насколько оно обязано это делать с удалёнными пайпами, например; ну и вообще, стрёмно пользоваться вещью, которая даже в качестве undocumented internal нигде не описана, а просто как-то наблюдаемо себя ведёт).

3. Есть ли какие-нибудь требования, кроме «неписанных традиций», к хэндлам, которые я отдаю дочернему процессу в качестве STD_ZZZ_HANDLE? Понятно, что на них должен работать non-overlapped I/O, но как, например, насчёт FILE_SYNCHRONOUS_IO_ALERT — имеет ли право дочерний процесс глючить из-за того, что блокирующие операции внезапно alertable? Или в этой области вообще никакого «имеет право» не бывает? (кстати, если передать OVERLAPPED сокет, у него будут аналогичные свойства по отношению к синхронным ReadFile и WriteFile: alertable wait в ситуации, когда его на обычных объектах нет).

4. Вопрос по "ненастоящим" хэндлам (console input, любезно предоставленный kernel32.dll и csrss). Обнаружился способ отменить блокирующий ReadConsole (представляем наихудшие условия, т.е. line input включён и никакое «ожидание перед вводом» проблем не решит): CloseHandle того хэндла, на котором ReadConsole висит, заставляет её завершиться (имеет значение именно совпадение хэндлов, т. е., например, результат DuplicateHandle и исходный хэндл в этом смысле различимы — чего для kernel objects, разумеется, никогда не бывает, но для консоли наблюдается). Проблема в том, что я не понимаю, как при этом избежать race condition: если я закрываю хэндл, на котором предположительно «висит» ReadConsole, до того, как она реально на нём повисла, а в это время соседняя нить делает DuplicateHandle консоли или, к примеру, CreateFile("CONIN$"...) — значение хэндла может быть переиспользовано и ReadConsole «повиснет» уже на чужом хэндле, что совсем нехорошо. Буду рад либо альтернативному способу обломать блокирующий ReadConsole (без глобальных последствий, т.е. не GenerateConsoleCtrlEvent, например) — либо решению проблемы способа с CloseHandle.

5. Вопрос по смежной тематике. Существует любопытный метод устранения самых вопиющих последствий TerminateThread (т.е. утекающей области стека): ConvertThreadToFiber(), TerminateThread(), DeleteFiber() [и дохлый стек удаляется]. Можно ли считать, что таким способом побеждены все утечки, если (1) в удаляемой нити не использовалось слотов TLS extensions и вообще делались только вызовы kernel32 и (2) вызовы DLL_PROCESS_ATTACH конкретно для этой нити мне как-то удалось предотвратить? (Понятно, что здесь никаких документированных гарантий быть не может, только практический опыт). Если, к примеру, известно, что в kernel space тоже что-то утекает — с этим я ничего не сделаю, это понятно (но у меня впечатление, что как раз «ядерная» часть нити сносится аккуратно, а проблемы создает исключительно userspace).

6. Пара ещё более нетематических вопросов на закуску: (6.1) не открыло ли прогрессивное человечество способа бороться с ненамеренным наследованием хэндлов, за исключением использования процесса-прокладки для CreateProcess? (появление WSA_FLAG_NO_HANDLE_INHERIT намекает, что не открыло, но мало ли); (6.2) утекают ли какие-нибудь ресурсы в сочетании ConvertThreadToFiber()+ExitThread() (вместо ConvertThreadToFiber+DeleteFiber(GetCurrentFiber()))? я этого не наблюдаю, но некоторые источники (впрочем, не слишком авторитетные) утверждают, что могут утекать.