Linux Kernel patch sent in for comments to help gaming

Does that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

Quoting: EikeDoes that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

My first thought, with no specific knowledge of the details, is that you would use a single event for all the possible sources and pass a parameter to indicate which. For system events, or a non-controlled application, probably set up multiple threads that wait each for a different event and then wakes up the thread you actually want.

But this is, of course, assuming that you are just adapting an existing code. When developing for Linux directly, people would just use a different algorithm that didn't rely on that; I don't think this is a particularly fundamental feature for multi-threaded development.

Quoting: EikeDoes that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

$ man poll
$ man select
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

Quoting: x_wing

Quoting: EikeDoes that mean there's no such thing as WaitMultipleObjects on Linux? How would a Linux programmer solve that?

$ man poll
$ man select
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

Quoting: ShabbyX

Quoting: x_wing$ man poll
$ man select
```
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

I guess that somewhat answers the question I would have asked:
Poll and select seem to be all about files, while...

QuoteThe WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

This still sounds useful to me.

Quoting: ShabbyXAnd more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

There is no way to use fds for synchronization without a syscall. That's no good for performance-critical paths. Pthreads primitives like mutex, condition, semaphore are designed to avoid syscalls where possible. Ideally (e.g. uncontended mutex lock) they use only atomic operations, but they call futex when they need to block, or to wake other threads.

Being able to wait on multiple futexes at once seems generally useful to me.

Linux supports waiting multiple objects, but only if they're backed by file descriptors, the problem with sincronization primitives is they frequently aren't, as a developer specialized on parallelism and distributed processing getting something like this mainlined would make me quite happy.

When i wanted to implement my own threading API on linux a few years ago, i found out that there were no system procedure to pause or resume a thread from another thread unlike Windows. You had to use signals for that and it was really messy.

Quoting: Code ArtisanWhen i wanted to implement my own threading API on linux a few years ago, i found out that there were no system procedure to pause or resume a thread from another thread unlike Windows. You had to use signals for that and it was really messy.

Suspending threads comes with so many caveats that on platforms there they do exits (i.e Windows) they are marked as not to be used by anything other than debuggers really, and you are instead referred to use the same kinds of thread to thread syncronization that you have on i.e Linux such as e.g condition variables.

Quoting: Eike

Quoting: ShabbyX

Quoting: x_wing$ man poll
$ man select
```
That's your answer.

I don't know what is the issue with wine, but I guess that their problem may be related to fd (but is mentioned as secondary improvement, so I'm not sure...)

And more recently, epoll. I don't know what their problem with fds are, but everything being an fd is the best thing to have happened to unix. Things that weren't an fd turned out to be the most problematic (pid, signals), and they are turning into fds in recent Linuxes too.

Maybe they can get windows-y programs to run faster with windows-y kernel features, but I certainly hope no one would use this feature outside wine.

I guess that somewhat answers the question I would have asked:
Poll and select seem to be all about files, while...

QuoteThe WaitForMultipleObjects function can specify handles of any of the following object types in the lpHandles array:

Change notification
Console input
Event
Memory resource notification
Mutex
Process
Semaphore
Thread
Waitable timer

This still sounds useful to me.

And out of that list it's mostly mutexes and semaphores where Linux is lacking (most of the others on that list have an equivalent and thus can be used with epoll). And being able to wait for a mutex or a semaphore with epoll would have been a very nice addition, BSD have kqueue where you can wait for both fd:s, signals and mutex/semaphores with the same function and it existed before epoll so quite a large number of people are upset that Linux went with their own API that had less functionality (that said I do prefer the API of epoll over kqueue, just the functionality that is lacking).

In the end it just means that you as a Linux developer write your application in a different way than what you would have done on Windows or BSD so the major problem comes with things like WINE since they have to support the WIN32 interface.

edit: It also have to be said that this patch does not solve the "listen to both fd:s and other stuff with the same interface" since it just implements a way to listen to several FUTEX:es at the same time.


Last edited by F.Ultra on 14 June 2020 at 2:56 pm UTC