Support for Handles on Windows

[yoshuawuyts]

Windows has two kinds file descriptors: Handle and Socket. It seems smol::Async currently only support Socket but not yet Handle, which is needed to abstract over APIs such as named pipes. What is the plan for Handle-based APIs in smol?

[sdroege]

Similar to fds on UNIX this has the problem that not all Handles are waitable from what I understand, so that would have to be documented carefully. For all others, WaitForMultipleObjects() and friends would work.

IMHO this would be useful to have.

[sdroege]

To add some more information here, this is not just named pipes but also for example: waitable timers (basically Windows' timerfd equivalent), event objects, semaphores, threads/processes, mutexes and probably various other things I forgot.

[sdroege]

wepoll only seems to support SOCKET unfortunately, so might not be a good choice going forward unless it gets support for HANDLE.

I think we could eventually add support for RawHandle through IOCP... but it's not at the top of my priority list, tbh.

[sdroege]

Makes sense and it's would only require internal changes anyway, not API-wise :)

[cr1901]

To add some more information here, this is not just named pipes but also for example: waitable timers (basically Windows' timerfd equivalent), event objects, semaphores, threads/processes, mutexes and probably various other things I forgot.

This isn't really a deal-breaker, but I was looking to play with reading Physical Disks using OVERLAPPED_IO. Not anything (that) useful, just something for-fun that I could use to help learn how async-io works.

Unfortunately, because there's no support for Handles, I can't actually open a Physical Disk to pass to Async to take care of "all the stuff that I don't feel like writing myself" :P.

[notgull]

Usage as you describe is currently blocked on smol-rs/polling#97. But, waitable handles like processes can be used in #152