4 ms·

The thing is, on Windows, you're not supposed to wait on a thousand handles at once. You're supposed to use overlapped I/O, completion ports, etc. which work qu

The thing is, on Windows, you're not supposed to wait on a thousand handles at once. You're supposed to use overlapped I/O, completion ports, etc. which work quite well.

monocasa 7y ago
This use case in the article isn't about I/O at all though. Futexes are user space mutexes. Overlapped I/O and completion ports don't help you in that case.
- mehrdadn 7y ago
  Right, but when do you need to simultaneously wait on more than 64 things other than for I/O? I've never had to wait on that many mutexes... (P.S. there is a really ugly way to get around this on Windows if for some bizarre reason you really need to, which is to have 1 thread per 64 handles, then wait on the thread handle instead. I've never found a need do even get close to doing such a thing though.)
  - monocasa 7y ago
    Off the top of my head, timers?
    - mehrdadn 7y ago
      Doesn't Windows have timers that actually notify you via window messages or callbacks (like SetTimer())?
      - monocasa 7y ago
        Windows has a ton of subsystem specific hacks each with their own drawbacks. Which brings me back to my main point against the GPs > They should just bite the bullet and implement WaitForMultipleObjects instead of having all these disjoint APIs
        mehrdadn 7y ago
        > Windows has a ton of subsystem specific hacks each with their own drawbacks. Is this your way of saying "I can't think of any legitimate response, but I insist the Windows API must suck because that's just how I feel about it"? I literally told you there is a proper solution that turns out to be different than what you're expecting coming from Linux, and instead of either realizing it's a good solution or telling me why it isn't, you just trashed the OS and told me it sucks.
        monocasa 7y ago
        It's my way of trying to keep the conversation on the topic of the actual article, rather than turning it into a generic Linus v Cutler boxing match where both of their syscall interfaces are on the table. And staying on the topic of mutexes, that "just spawn another thread for every 64 items you want to wait on" (which I already knew about) is about the hackiest shit ever. (And FWIW, I started off as a Win32 developer, have code in ReactOS, and have written NT and WinCE drivers. You're not talking to some Linux fanboy)
        mehrdadn 7y ago
        > And staying on the topic of mutexes, that "just spawn another thread for every 64 items you want to wait on" (which I already knew about) is about the hackiest shit ever. Is this surprising to you? I already told you it would be a hack because I told you there is a better and proper solution for the actual problem you were encountering. You're stubbornly insisting for no reason on actively doing something bizarre, and you're frustrated you need an obtuse hack to make it happen? If you're trying so hard to "stay on the topic of mutexes" why do you trash WFMO for the "silly 64 item cap" and then repeatedly refuse to provide a single situation in which waiting on 64 mutexes would actually come up as a legitimate problem? Somehow you find the inability to use a wrong method to solve a problem whose existence you can't even show evidence of to be "silly"?
        monocasa 7y ago
        Windows runs on single socket systems with 128 cores. If you can't think of some time you might need to wait on more than 64 items at a time, you only have your own lack of imagination to blame.
    - ComputerGuru 7y ago
      Maybe, but only if you are doing it wrong. Pro-tip: look up hashed wheel timers.
      - monocasa 7y ago
        Pro tip: implementing a hashed wheel timer yourself in user space comes with weird jitter because you can't atomically grab the system time and sleep for the next tick. Which is why all the sane OSes implement it or something like it in kernel space, including NT.
        ComputerGuru 7y ago
        It’s not about implementing it more efficiently in a universal sense, it’s about making fewer unnecessary trips to the kernel and back. Context switches probably introduce more jitter than your userspace hashed timer wheel.

The thing is, on Windows, you're not supposed to wait on a thousand handles at once. You're supposed to use overlapped I/O, completion ports, etc. which work quite well.

monocasa 7y ago

This use case in the article isn't about I/O at all though. Futexes are user space mutexes. Overlapped I/O and completion ports don't help you in that case.

mehrdadn 7y ago
Right, but when do you need to simultaneously wait on more than 64 things other than for I/O? I've never had to wait on that many mutexes... (P.S. there is a really ugly way to get around this on Windows if for some bizarre reason you really need to, which is to have 1 thread per 64 handles, then wait on the thread handle instead. I've never found a need do even get close to doing such a thing though.)
- monocasa 7y ago
  Off the top of my head, timers?
  - mehrdadn 7y ago
    Doesn't Windows have timers that actually notify you via window messages or callbacks (like SetTimer())?
    - monocasa 7y ago
      Windows has a ton of subsystem specific hacks each with their own drawbacks. Which brings me back to my main point against the GPs > They should just bite the bullet and implement WaitForMultipleObjects instead of having all these disjoint APIs
      - mehrdadn 7y ago
        > Windows has a ton of subsystem specific hacks each with their own drawbacks. Is this your way of saying "I can't think of any legitimate response, but I insist the Windows API must suck because that's just how I feel about it"? I literally told you there is a proper solution that turns out to be different than what you're expecting coming from Linux, and instead of either realizing it's a good solution or telling me why it isn't, you just trashed the OS and told me it sucks.
        monocasa 7y ago
        It's my way of trying to keep the conversation on the topic of the actual article, rather than turning it into a generic Linus v Cutler boxing match where both of their syscall interfaces are on the table. And staying on the topic of mutexes, that "just spawn another thread for every 64 items you want to wait on" (which I already knew about) is about the hackiest shit ever. (And FWIW, I started off as a Win32 developer, have code in ReactOS, and have written NT and WinCE drivers. You're not talking to some Linux fanboy)
        mehrdadn 7y ago
        > And staying on the topic of mutexes, that "just spawn another thread for every 64 items you want to wait on" (which I already knew about) is about the hackiest shit ever. Is this surprising to you? I already told you it would be a hack because I told you there is a better and proper solution for the actual problem you were encountering. You're stubbornly insisting for no reason on actively doing something bizarre, and you're frustrated you need an obtuse hack to make it happen? If you're trying so hard to "stay on the topic of mutexes" why do you trash WFMO for the "silly 64 item cap" and then repeatedly refuse to provide a single situation in which waiting on 64 mutexes would actually come up as a legitimate problem? Somehow you find the inability to use a wrong method to solve a problem whose existence you can't even show evidence of to be "silly"?
        monocasa 7y ago
        Windows runs on single socket systems with 128 cores. If you can't think of some time you might need to wait on more than 64 items at a time, you only have your own lack of imagination to blame.
  - ComputerGuru 7y ago
    Maybe, but only if you are doing it wrong. Pro-tip: look up hashed wheel timers.
    - monocasa 7y ago
      Pro tip: implementing a hashed wheel timer yourself in user space comes with weird jitter because you can't atomically grab the system time and sleep for the next tick. Which is why all the sane OSes implement it or something like it in kernel space, including NT.
      - ComputerGuru 7y ago
        It’s not about implementing it more efficiently in a universal sense, it’s about making fewer unnecessary trips to the kernel and back. Context switches probably introduce more jitter than your userspace hashed timer wheel.