4 ms·

Windows has no right to trash-talk: WaitForMultipleObjects() is one of the most depressing select-like APIs out there.

by ktRolster 10y ago

GauntletWizard 10y ago
Not being familiar, it looks pretty standard. What're it's negative attributes?
- ktRolster 10y ago
  Conceptually, select() can wait on anything that's a file descriptor. WaitForMultipleObjects() can only work on things that were specifically added to its capability list. Practically, MAXIMUM_WAIT_OBJECTS is set to such a low number (64) that people resort to this kind of hack: https://msdn.microsoft.com/en-us/library/windows/desktop/ms687055(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
  - xorblurb 10y ago
    IIRC there are even advanced Win32 API that, so that you can go above MAXIMUM_WAIT_OBJECTS, ... automatically handle a thread poll! That kind of "solution" to such a problem is way more insane than epoll() eventually providing the correct flags to fix most of its own issues, even if we had to wait during a decade for it... So praising NT because epoll is "trash" is uninformed at best, malicious at worst.
unscaled 10y ago
WaitForMultipleObjects sucks, but that's because it got very little love since Windows 95. That's because Microsoft seems to have completely abandoned the Reactor (select/epoll wake-on-readiness) pattern in favor of the Proactor (IOCP-like wake-on-event/completion) pattern. With the proactor pattern, you register events you care about explicitly, and your event-loop gets the next event to handle and schedules the respective callback/coroutine/future to handle that event. With the reactor pattern you don't have explicit registration for completion status when you do an I/O operation, and you need to explicitly specify the file descriptors you want to select on in the point where you select on them. Many people (including the author of the OP article) think that proactor is superior, and this was what the Windows guy in the parent post was referring to. In Windows you're NEVER SUPPOSED to use any version of select (including WSAAsyncSelect or WaitForMultipleObjects) if you have a large number of events. They don't scale. Instead, Microsoft decided to put its scaling effort into the proactor approach, which they introduced in Windows NT 3.5 -almost a decade before Linux came out with epoll - and this was the right way to do async I/O on Windows ever since. Linux, on the other hand, chose to perfect the reactor model, and with epoll it gave a very powerful select-like reactor implementation[1]. So yes, if you specifically want to program a reactor, go with Linux. Reactor-centric software and libraries (like libev or nginx) just don't scale on Windows. But that doesn't mean async I/O on Windows sucks - it's just optimized for a different model. [1] kqueue could be better, but I don't know it well enough to make a call. And while it's I/O events are readiness based, as far as I understand it's general enough that it can be used to implement a proactor as well.
trentnelson 10y ago
That is actually an excellent API; you can wait for up to 64 arbitrary events in a relatively efficient manner. You should never, ever use it for high performance I/O.

Windows has no right to trash-talk: WaitForMultipleObjects() is one of the most depressing select-like APIs out there.

GauntletWizard 10y ago

Not being familiar, it looks pretty standard. What're it's negative attributes?

ktRolster 10y ago
Conceptually, select() can wait on anything that's a file descriptor. WaitForMultipleObjects() can only work on things that were specifically added to its capability list. Practically, MAXIMUM_WAIT_OBJECTS is set to such a low number (64) that people resort to this kind of hack: https://msdn.microsoft.com/en-us/library/windows/desktop/ms687055(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
- xorblurb 10y ago
  IIRC there are even advanced Win32 API that, so that you can go above MAXIMUM_WAIT_OBJECTS, ... automatically handle a thread poll! That kind of "solution" to such a problem is way more insane than epoll() eventually providing the correct flags to fix most of its own issues, even if we had to wait during a decade for it... So praising NT because epoll is "trash" is uninformed at best, malicious at worst.

unscaled 10y ago

WaitForMultipleObjects sucks, but that's because it got very little love since Windows 95. That's because Microsoft seems to have completely abandoned the Reactor (select/epoll wake-on-readiness) pattern in favor of the Proactor (IOCP-like wake-on-event/completion) pattern. With the proactor pattern, you register events you care about explicitly, and your event-loop gets the next event to handle and schedules the respective callback/coroutine/future to handle that event. With the reactor pattern you don't have explicit registration for completion status when you do an I/O operation, and you need to explicitly specify the file descriptors you want to select on in the point where you select on them. Many people (including the author of the OP article) think that proactor is superior, and this was what the Windows guy in the parent post was referring to. In Windows you're NEVER SUPPOSED to use any version of select (including WSAAsyncSelect or WaitForMultipleObjects) if you have a large number of events. They don't scale. Instead, Microsoft decided to put its scaling effort into the proactor approach, which they introduced in Windows NT 3.5 -almost a decade before Linux came out with epoll - and this was the right way to do async I/O on Windows ever since. Linux, on the other hand, chose to perfect the reactor model, and with epoll it gave a very powerful select-like reactor implementation[1]. So yes, if you specifically want to program a reactor, go with Linux. Reactor-centric software and libraries (like libev or nginx) just don't scale on Windows. But that doesn't mean async I/O on Windows sucks - it's just optimized for a different model. [1] kqueue could be better, but I don't know it well enough to make a call. And while it's I/O events are readiness based, as far as I understand it's general enough that it can be used to implement a proactor as well.

trentnelson 10y ago

That is actually an excellent API; you can wait for up to 64 arbitrary events in a relatively efficient manner. You should never, ever use it for high performance I/O.