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

101–110 of 158 posts

Re: Implement mechanism to wait on any of several futexes

#101

Post by mehrdadn »

monocasa wrote: post #97
mehrdadn wrote: post #96

Earlier quoted context omitted.

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.)

Off the top of my head, timers?

Doesn't Windows have timers that actually notify you via window messages or callbacks (like SetTimer())?

Re: Implement mechanism to wait on any of several futexes

#102

Post by LukeShu »

danappelxx wrote: post #87
Shorel wrote: post #71

Earlier quoted context omitted.

Games in Windows can get raw mouse input just by writing the code for it, and Linux games usually don't because that would require root permissions, to add the user to the input group, etc. It is a security issue and an X-Window design issue.

Oblivious question: is there any notion of granulated permissions, ie a ‘mouse’ user group that the game could add itself to? Seems like something like this shouldn’t be a deal-breaker.

There is an 'input' user group, which gives you access to raw mouse, keyboard, joystick, et c. under `/dev/input/`. (I'm sure you could configure udev to use more more granular user groups for different types of input devices, if you really wanted). Normal human users of a single-user system should be members of the 'input' group, so this "should" be a non-issue.

Re: Implement mechanism to wait on any of several futexes

#103

Post by wahern »

The `abs_time` argument to both the futex_wait and new futex_wait_multiple is a pointer, but nowhere is the address checked for validity. (Tracing the syscall path, it seems to be dereferenced in futex_setup_timer without any validity check beforehand.) It's never written to AFAICT, only loaded, but it still seems like leaving around a loaded gun. More importantly, couldn't this unchecked address be used to probe kernel memory to test for values like NULL, or possibly any value with enough sampling?

Note that the futex address itself is also a pointer, but it's validated with access_ok in get_futex_key.

Re: Implement mechanism to wait on any of several futexes

#104

Post by k_sze »

LukeShu wrote: post #99
Shorel wrote: post #71

Earlier quoted context omitted.

Games in Windows can get raw mouse input just by writing the code for it, and Linux games usually don't because that would require root permissions, to add the user to the input group, etc. It is a security issue and an X-Window design issue.

Normal human users will/should almost always be members of the 'input' group.

Maybe being a member of the input group allows you to spy on other users? Just maybe. I don’t know Linux well enough.

Re: Implement mechanism to wait on any of several futexes

#105

Post by wbl »

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.

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

Re: Implement mechanism to wait on any of several futexes

#106

Post by monocasa »

wahern wrote: post #103

The `abs_time` argument to both the futex_wait and new futex_wait_multiple is a pointer, but nowhere is the address checked for validity. (Tracing the syscall path, it seems to be dereferenced in futex_setup_timer without any validity check beforehand.) It's never written to AFAICT, only loaded, but it still seems like leaving around a loaded gun. More importantly, couldn't this unchecked address be used to probe ker…

It's not a user pointer, it's a pointer to the kernel stack that's constructed here:

https://elixir.bootlin.com/linux/latest/source/kernel/futex....

Re: Implement mechanism to wait on any of several futexes

#107

Post by monocasa »

mehrdadn wrote: post #101
monocasa wrote: post #97

Earlier quoted context omitted.

Off the top of my head, timers?

Doesn't Windows have timers that actually notify you via window messages or callbacks (like SetTimer())?

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

Re: Implement mechanism to wait on any of several futexes

#108

Post by mehrdadn »

monocasa wrote: post #107
mehrdadn wrote: post #101

Earlier quoted context omitted.

Doesn't Windows have timers that actually notify you via window messages or callbacks (like SetTimer())?

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

> 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.

Re: Implement mechanism to wait on any of several futexes

#109

Post by monocasa »

mehrdadn wrote: post #108
monocasa wrote: post #107

Earlier quoted context omitted.

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

> 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 developer, have code in ReactOS, and have written NT and WinCE drivers. You're not talking to some Linux fanboy)

Re: Implement mechanism to wait on any of several futexes

#110

Post by swiley »

zamalek wrote: post #84
swiley wrote: post #29

This looks to me like the main change is to make it easier to create mutexes with timeouts. Isn’t a mutex timing out an indication that: a) a lock wasn’t needed in the first place or b) the program is incorrect? It feels more like they just want the api to match win32 better but most of the multithreaded programming I’ve done lately has just used go’s channels so I totally could be missing something.

One valid scenario for mutexes timing out is stealing: 1. Each CPU first attempts to take an allocated object from its own pool, using a 1ms timeout to acquire the mutex on the pool. 2. If that fails, the CPU attempts to steal from the other CPU pools, using a zero timeout (immediately return if the mutex can't be taken). 3. If that fails, acquire the mutex on its own pool with an infinite timeout. This is definitely…

That totally makes sense, thanks for correcting me. :)
Post reply on HN