Support waitable objects on Windows 10

[Demi-Marie]

There is an (undocumented) NtAssociateWaitCompletionPacket syscall that can be used for the purpose.

This would resolve issue https://github.com/stjepang/smol/issues/24

Do you perhaps know of any unofficial documentation on NtAssociateWaitCompletionPacket or maybe even a project using it?

[DemiMarie]

ProcessHacker has a function prototype but I don’t know of anyone else using it. Fortunately, the argument names should be fairly self-explanatory.

[notgull]

I'd rather avoid using a system call that's entirely undocumented (this issue is the second result on Google when I look up the function name). Is there a way to work this into wepoll?

[DemiMarie]

@notgull Maybe? wepoll already uses undocumented Windows internals so this would not be new.

[notgull]

I'm honestly not a big fan of that either, since it has led to breakages on certain platforms (e.g. Wine) and could very easily break with no warning on future versions of Windows. However at this point the only alternatives are explicitly deprecated (WSAAsyncSelect) or incompatible with the current API (I/O Completion Ports), so I'm unsure as to what it would be replaced with.

What I'm trying to say is that we already rely on enough unstable behavior, and there's no need to build onto that house of cards more than we already do.

[DemiMarie]

I'm honestly not a big fan of that either, since it has led to breakages on certain platforms (e.g. Wine) and could very easily break with no warning on future versions of Windows.

libuv already relies on the same behavior, so such breakage would be noticed pretty quickly.

However at this point the only alternatives are explicitly deprecated (WSAAsyncSelect) or incompatible with the current API (I/O Completion Ports), so I'm unsure as to what it would be replaced with.

NtAssociateWaitCompletionPacket can only be used with I/O completion ports. Its purpose is to support objects that IOCP does not.

One alternative would be to use the Windows thread pool API, but I doubt that would be compatible.

[notgull]

As of smol-rs/polling#98, waitable handles can be waited on in polling. It shouldn't be too hard to expose this in async-io.