Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implement mechanism to wait on any of several futexes

lkml.org

Post reply on HN
Print view View original

111–120 of 158 posts

Re: Implement mechanism to wait on any of several futexes

#111

Post by mehrdadn »

monocasa wrote: post #109
mehrdadn wrote: post #108

Earlier quoted context omitted.

> 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 m…

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 develop…

> 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"?

Re: Implement mechanism to wait on any of several futexes

#112

Post by jlokier »

jdsully wrote: post #80

I like how they won’t say the windows API’s name. WaitForMultipleObjects is quite nice - an epoll that works with all sorts of things not just fds. This is kind of a half assed implementation - sometimes I wish Linux would admit Windows has a good idea once in a while.

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.

Re: Implement mechanism to wait on any of several futexes

#113

Post by sandov »

ilikehurdles wrote: post #55
gnufied wrote: post #46

Personally for me - the problematic part of gaming on Linux has been input(i.e mouse) latency and acceleration profile. I am not sure if this is just my experience but when using libinput on Fedora for example - the cursor movement is not exactly precise. This is not obvious when working but while gaming this is a deal breaker.

There is a "flat" profile that can be toggled in the Gnome Tweak Tool, assuming you're using Gnome in Fedora.

Last time I tried it, flat didn't work correctly when using a touchpad, only when using a mouse.

Touchpad flat profile was flat up to a certain velocity, but when you exceeded that it accelerated a lot.

Flat profile on a physical mouse worked correctly. Even if I yanked the device, it wouldn't accelerate.

This is one of the reasons why I'm sticking to Ubuntu 16.04: "xset m 1 0" disables all acceleration on xinput.

Re: Implement mechanism to wait on any of several futexes

#114

Post by db48x »

peterzz wrote: post #70
db48x wrote: post #24

Earlier quoted context omitted.

Agreed. Also "missing {}" is a super important "style" comment.

Because bugs due to missing {} happen, and are a royal pain, the rule is that any nontrivial statement; especially any multi-line; must have braces. Also, given the amount of patches I have to read, uniform style really does matter. Unconventional style breaks the flow and detracts from the important bits. Also, I'm not aware of a lint like tool that works on diffs. Many of the patches never get further than my MUA.

I think you took my comment as sarcasm, but I quite agree with you; being able to leave out the curly braces was a mistake in the language design. Not as big as some of the others, but costly enough over all these decades.

Personally I prefer to be less strict about style whenever possible, but then I prefer to work in safer languages, and I don't have the same firehose to deal with.

Re: Implement mechanism to wait on any of several futexes

#115

Post by sjwright »

rimunroe wrote: post #14
sjwright wrote: post #10

Earlier quoted context omitted.

The thing to remember is that version numbers aren’t decimals. They’re two or three integers separated by periods. 11 is higher than 2.

I don't know what the source of this convention is, but this is why I was taught that the version "1.2.3" should be read aloud as "one dot two dot three" instead of "one point two point three". The idea is that people--where I'm from at least--tend to read decimals as "point" and not "dot".

Yes, sadly the proliferation of the "two point oh" meme has set society back on that front. (Had we the opportunity to start over, I would have proposed different punctuation for the delimiter to avoid natural confusion with decimals.)

Re: Implement mechanism to wait on any of several futexes

#116

Post by dingu »

jdsully wrote: post #89
monocasa wrote: post #88

Earlier quoted context omitted.

This isn't really like WaitForMultipleObjects; WFMO is more like epoll with a whole lot more restrictions. This legit isnt really like anything in Windows, the closest thing I can think of is you'd be able to do something like this with XOK wake predicates.

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.

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.

Re: Implement mechanism to wait on any of several futexes

#117

Post by jdsully »

jlokier wrote: post #112
jdsully wrote: post #80

I like how they won’t say the windows API’s name. WaitForMultipleObjects is quite nice - an epoll that works with all sorts of things not just fds. This is kind of a half assed implementation - sometimes I wish Linux would admit Windows has a good idea once in a while.

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 "waitin…

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

Re: Implement mechanism to wait on any of several futexes

#118

Post by asveikau »

jdsully wrote: post #80

I like how they won’t say the windows API’s name. WaitForMultipleObjects is quite nice - an epoll that works with all sorts of things not just fds. This is kind of a half assed implementation - sometimes I wish Linux would admit Windows has a good idea once in a while.

WaitForMultipleObjects is problematic for a few reasons:

* limited to 64 handles.

* passes the entire handle buffer to the kernel on every call. That is also a key reason poll is worse than epoll/kqueue. A better way is to let the kernel retain the list of handles across calls.

* when two handles are signalled, the one earlier in the array is always the one returned. So handle with a lower array index being frequently signalled can starve out your opportunity to process the later ones.

* since everything happens by returning an index, when multiple handles are signalled, you can only process one at a time, needing a new syscall for each.

Re: Implement mechanism to wait on any of several futexes

#119

Post by dingu »

jdsully wrote: post #117
jlokier wrote: post #112

Earlier quoted context omitted.

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 "waitin…

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

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.

Re: Implement mechanism to wait on any of several futexes

#120

Post by jdsully »

dingu wrote: post #119
jdsully wrote: post #117

Earlier quoted context omitted.

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

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.

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.

Post reply on HN