9 ms·

Linux has WaitForMultipleObjects already: fds are equivalent to Windows HANDLEs, and WaitForMultipleObjects() is equivalent to poll(). But, Linux also has epo

Linux has WaitForMultipleObjects already: fds are equivalent to Windows HANDLEs, and WaitForMultipleObjects() is equivalent to poll(). But, Linux also has epoll() which scales better for non-trivial numbers of things, and Windows has IOCP. So WaitForMultipleObjects isn't particularly special. Both Windows and Linux have things that don't work with these interfaces. Nonetheless, Linux has been trending towards "waiting on all sorts of things" by makng more and more things into fds that can be waited on with pol;/epoll. Examples: timerfd, signalfd, eventfd. It's quite a unixy approach. In fact, Wine already uses eventfd to implement WaitForMultipleObjects. This kernel change is just an optimisation, to speed up Wine, and a workaround for some distros setting Wine's max fd limit too low for Windows apps. Futexes used to support waiting on multiple futexes, using FUTEX_FD. That was arguably better than the new patch FUTEX_WAIT_MULTIPLE, because in old Linux you could wait for futexes and other fds at the same time - it did work with "all sorts of things". But FUTEX_FD was removed after searches online found no code using it, and kernel devs didn't like keeping it. (To my mind, this was a suprising, unusual breakage of system call binary compatibility) The new FUTEX_WAIT_MULTIPLE allows programs like Wine to wait for multiple futexes faster than before, but it's more limited than the old FUTEX_FD because you can't mix them with other things.

jdsully 7y ago
epoll only works with file descriptors and is therefore not equivalent. The whole point is WaitForMultipleObjects works with many different types.
- dingu 7y ago
  You are confused. File descriptors on linux represent "many different types." They are not just for "disk files". Please see signalfd, timerfd, eventfd, inotify, let alone sockets (which themselves represent things other than IP sockets). FD is essentially like handle. epoll therefore works with many different types.
  - jdsully 7y ago
    While the Unix philosophy is that everything is a file - that is not the case with Linux. Futexs being a good example. There was an attempt to integrate them but it was done incorrectly with inherent race conditions and abandoned. The VMS and NT philosophies of everything being an object are a bit more general and easier to follow in practice.
    - dingu 7y ago
      what are you on about? I just gave you the specific examples: timerfd, eventfd, signalfd, inotify... these are all epollable fds in Linux? Futex is a special case because futexes themselves are quite special. There is no userspace equivalent to them in Windows anyway as has been mentioned. Windows Events are similar to what is provided by eventfd, but not as featureful.
      - ithkuil 7y ago
        Probably the core of the issue here is that VMS and derivatives tried to hard to fit everything into a generic handle/fd interface while UNIX historically came with a smaller core with many important API surfaces (like signals or timers) only relatively recently getting absorbed under the unified handle/fd interface, giving the impression it's an afterthought. It's also not something that works on all Unices (e.g. afaik macos has no timerfd). But in all fairness, that problem only exists because OS speciation, as it's biological counterpart, is not as clear cut a concept as one would desire.
        monocasa 7y ago
        Macos timers can be waited on via kqueue FWIW.
        ithkuil 7y ago
        I know; but they cannot be closed with close, or passed via unix domain sockets to other processes etc etc. I _think_ this whole thread is about "purity", whatever that means.
- monocasa 7y ago
  The vast majority of the interesting types _are_ files under Linux. You can use epoll with files, signals, timers, sockets, pipes, kernel semaphores, other epoll descriptors, page fault handling descriptors, etc. FDs are pretty much HANDLEs of the nix world.
  - cryptonector 7y ago
    HANDLEs are better. And on Windows you get HANDLEs to processes. We could have that in *nix land, you know.. something like opening /proc/$victim/status and using it to wait for the process and keep its PID from being reused until this is closed.
    - cesarb 7y ago
      > We could have that in *nix land, you know.. something like opening /proc/$victim/status and using it to wait for the process and keep its PID from being reused until this is closed. We are going to soon: "The 5.3 kernel also adds the ability to pass a pidfd to poll(), which will provide a notification when the process represented by that pidfd exits." (https://lwn.net/SubscriberLink/794707/905eb6b5b7287e77/ https://lwn.net/SubscriberLink/794707/905eb6b5b7287e77/)
  - atombender 7y ago
    Last I heard, epoll() was, ironically, not useful with actual file descriptors, because file I/O isn't blocking on Linux [1]. I'm not sure if this problem has been remedied in recent years. [1] https://stackoverflow.com/questions/8057892/epoll-on-regular-files https://stackoverflow.com/questions/8057892/epoll-on-regular...

jdsully 7y ago

epoll only works with file descriptors and is therefore not equivalent. The whole point is WaitForMultipleObjects works with many different types.

dingu 7y ago
You are confused. File descriptors on linux represent "many different types." They are not just for "disk files". Please see signalfd, timerfd, eventfd, inotify, let alone sockets (which themselves represent things other than IP sockets). FD is essentially like handle. epoll therefore works with many different types.
- jdsully 7y ago
  While the Unix philosophy is that everything is a file - that is not the case with Linux. Futexs being a good example. There was an attempt to integrate them but it was done incorrectly with inherent race conditions and abandoned. The VMS and NT philosophies of everything being an object are a bit more general and easier to follow in practice.
  - dingu 7y ago
    what are you on about? I just gave you the specific examples: timerfd, eventfd, signalfd, inotify... these are all epollable fds in Linux? Futex is a special case because futexes themselves are quite special. There is no userspace equivalent to them in Windows anyway as has been mentioned. Windows Events are similar to what is provided by eventfd, but not as featureful.
    - ithkuil 7y ago
      Probably the core of the issue here is that VMS and derivatives tried to hard to fit everything into a generic handle/fd interface while UNIX historically came with a smaller core with many important API surfaces (like signals or timers) only relatively recently getting absorbed under the unified handle/fd interface, giving the impression it's an afterthought. It's also not something that works on all Unices (e.g. afaik macos has no timerfd). But in all fairness, that problem only exists because OS speciation, as it's biological counterpart, is not as clear cut a concept as one would desire.
      - monocasa 7y ago
        Macos timers can be waited on via kqueue FWIW.
        ithkuil 7y ago
        I know; but they cannot be closed with close, or passed via unix domain sockets to other processes etc etc. I _think_ this whole thread is about "purity", whatever that means.
monocasa 7y ago
The vast majority of the interesting types _are_ files under Linux. You can use epoll with files, signals, timers, sockets, pipes, kernel semaphores, other epoll descriptors, page fault handling descriptors, etc. FDs are pretty much HANDLEs of the nix world.
- cryptonector 7y ago
  HANDLEs are better. And on Windows you get HANDLEs to processes. We could have that in *nix land, you know.. something like opening /proc/$victim/status and using it to wait for the process and keep its PID from being reused until this is closed.
  - cesarb 7y ago
    > We could have that in *nix land, you know.. something like opening /proc/$victim/status and using it to wait for the process and keep its PID from being reused until this is closed. We are going to soon: "The 5.3 kernel also adds the ability to pass a pidfd to poll(), which will provide a notification when the process represented by that pidfd exits." (https://lwn.net/SubscriberLink/794707/905eb6b5b7287e77/ https://lwn.net/SubscriberLink/794707/905eb6b5b7287e77/)
- atombender 7y ago
  Last I heard, epoll() was, ironically, not useful with actual file descriptors, because file I/O isn't blocking on Linux [1]. I'm not sure if this problem has been remedied in recent years. [1] https://stackoverflow.com/questions/8057892/epoll-on-regular-files https://stackoverflow.com/questions/8057892/epoll-on-regular...