4 ms·
>IIRC, WaitForMultipleObjects can only block on 63 handles Yup (64 though), it's an extra annoying limitation. It has been there since the 90s, WinNT (cant rec
by xxs 6y ago
>IIRC, WaitForMultipleObjects can only block on 63 handles
Yup (64 though), it's an extra annoying limitation. It has been there since the 90s, WinNT (cant recall win95 version as I never used it with win95). It's limited by MAXIMUM_WAIT_OBJECTS which is 64.
For instance Java implements non-blocking IO (java.nio.Selector) by using multiple threads and sync between them to effectively achieve linux' epoll.
----
my point was mostly that the 'huge' 4% happens with massive amounts of threads and WaitForMultipleObjects won't see even that... so kind of click-baity. Flip note: sync. between threads can be done better than relying on OS primitives aside for real wait/notify stuff (which indeed it's implemented via futex)
- userbinator 6y agoLinux has a similar limitation with FD_SETSIZE and select() --- which I believe comes from the implementation using an array index operation instead of a more complex data structure due to performance reasons.
- throwaway2037 6y agoI'm confused by this comment. It appears to imply that FD_SETSIZE is also very small (63?) on Linux. To be clear: I am no an expert on Linux kernal params, nor select() and its friends. However, recent Linux kernels appears to have FD_SETSIZE about 1024. Red Hat says: <<FD_SETSIZE is hardcoded to 1024 in /usr/include/bits/typesizes.h and can not be changed.>> Source: https://access.redhat.com/solutions/488623 https://access.redhat.com/solutions/488623 If I misunderstand, please let me know.
- userbinator 6y agoI wasn't implying it's also small, but that it's a fixed value too.
- throwaway2037 6y agoVery good. Thank you to clarify.
- asveikau 6y agoI don't remember if the ABI kind of made it so that they can't increase that constant. Like if the next meaningful return code started at 65... As I recall they had this WAIT_OBJECT_0 + offset scheme, maybe offset 65 was something else meaningful? It's been a while. But if they had meaningfully increased that, then they would run into the same scaling problems as poll(2) - since the return code gives you an index, you wouldn't have to loop through the handle set in user mode like pollfd requires, but every syscall would need an O(n) scan of the HANDLE[] array on the kernel side. You need something like iocp/epoll/kqueue where kernel mode has a list of interesting handles, that doesn't need to be scanned and copied at every syscall.