4 ms·

Thats my point. They should just bite the bullet and implement WaitForMultipleObjects instead of having all these disjoint APIs. Plus sometimes you want to wait

Thats my point. They should just bite the bullet and implement WaitForMultipleObjects instead of having all these disjoint APIs. Plus sometimes you want to wait for both and this is very difficult with Linux. Its also telling Linux has gone through the whole select/poll/epoll madness while WaitForMultipleObjects has worked well in windows NT since the 90s. Its a proven design.

monocasa 7y ago
I mean.. epoll is already better than WFMO. It doesn't have that silly 64 item cap, or O(N) entry and exit on the wait like it's 1995 all over again. (And that's not to say that epoll is the pinnacle of design, just that WFMO is worse. We can do better than both) And this better too, you don't need to register futexes with the kernel, the futex wait call is just "I want to sleep until the data at this memory address changes", and now you can say "I want to sleep until _these addresses_ change". NT doesn't give you any equivalent, you need to build in kernel objects to do the same thing. And if you want to wait for both, you just wrap it into an eventfd and epoll on that.
- mehrdadn 7y ago
  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)
wbl 7y ago
Poll and select predate linux. The issues with epoll were in the 2000's and kqueue has been very stable by comparison.
- jdsully 7y ago
  Kqueue is quite nice. BSD is much better designed and I enjoy working with it more. Linux suffers from people doing just enough to solve their specific problem and then no more. The result is APIs are not orthogonal and follow differing styles. Sometimes they don’t even work at all (e.g. futex fds) I admire what Linux accomplishes functionally. But it is just as ugly as win32 in my opinion. The two are really more alike in their pragmatism than they would care to admit - but mutual hatred prevents learning from each others mistakes.
  - wbl 7y ago
    I've never worked with Win32, just read about the more core bits of NT, and those seem quite nice although perhaps overgeneral. But I've always had a soft spot for oddball systems.
dingu 7y ago
epoll was a problem child API on linux, with a number of missteps early on. It's much better now. It does everything WFMO does and more. What disjoint APIs are you talking about? You can just use epoll and be done with it? What are you talking about by "wait for both"? But jesus, the windows API in this area is hot garbage. A hard 64 limit and O(N)? It's a terrible design.

monocasa 7y ago

I mean.. epoll is already better than WFMO. It doesn't have that silly 64 item cap, or O(N) entry and exit on the wait like it's 1995 all over again. (And that's not to say that epoll is the pinnacle of design, just that WFMO is worse. We can do better than both) And this better too, you don't need to register futexes with the kernel, the futex wait call is just "I want to sleep until the data at this memory address changes", and now you can say "I want to sleep until _these addresses_ change". NT doesn't give you any equivalent, you need to build in kernel objects to do the same thing. And if you want to wait for both, you just wrap it into an eventfd and epoll on that.

mehrdadn 7y ago
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)

wbl 7y ago

Poll and select predate linux. The issues with epoll were in the 2000's and kqueue has been very stable by comparison.

jdsully 7y ago
Kqueue is quite nice. BSD is much better designed and I enjoy working with it more. Linux suffers from people doing just enough to solve their specific problem and then no more. The result is APIs are not orthogonal and follow differing styles. Sometimes they don’t even work at all (e.g. futex fds) I admire what Linux accomplishes functionally. But it is just as ugly as win32 in my opinion. The two are really more alike in their pragmatism than they would care to admit - but mutual hatred prevents learning from each others mistakes.
- wbl 7y ago
  I've never worked with Win32, just read about the more core bits of NT, and those seem quite nice although perhaps overgeneral. But I've always had a soft spot for oddball systems.

dingu 7y ago

epoll was a problem child API on linux, with a number of missteps early on. It's much better now. It does everything WFMO does and more. What disjoint APIs are you talking about? You can just use epoll and be done with it? What are you talking about by "wait for both"? But jesus, the windows API in this area is hot garbage. A hard 64 limit and O(N)? It's a terrible design.