-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pthread_mutexattr_init() returns ENOSYS #1006
Comments
Thanks for reporting the issue. Could you please share out a strace of the failing sample so we can see what syscall pthread_mutexattr_init is using internally? Didn't see that looking through the post or the other one that was linked. |
Trace:
|
Thanks, appreciate the help! I double checked in the code that FUTEX_UNLOCK_PI is not supported but we are tracking improvements in futex. |
Is this atom editor exception related ?
|
Yes Atom/Electron is built on top of the large popular software package here. |
Pinging this, and renewing my query from #996 (message) whether this can be faked for the time being. I assume mapping priority semantics to NT isn't trivial, else it would have happened already. So, my humble request is to tell userspace they are getting priority wakeup semantics, but give them normal semantics. If an application is depending on priority semantics it might not work. Maybe. But doing this won't break anything that isn't already broken by virtue of the failed system call. Here's a typical pattern I see in straces out of (I think)
It just falls back. Much other code hard fails on the While I am here, a quick correction on my original issue submission above, where I cited GN. That was incorrect. It looks like GN's beef is with #1353. Still, the |
Thanks for the reminder Ken! Just to clarify the asks, it's FUTEX_UNLOCK_PI, FUTEX_CMP_REQUEUE_PRIVATE, and proper zombie support, right? |
Yes, those would go a long way. Technically the two in the wild are |
Marking this as a bug so we can track the request for FUTEX_UNLOCK_PI, FUTEX_CMP_REQUEUE_PRIVATE, and proper zombie support. |
@stehufntdev - If it helps prioritize post-Creators any, the |
I've checked in a change that adds support for FUTEX_REQUEUE and FUTEX_CMP_REQUEUE (and the _PRIVATE versions obviously). Priority-inheritance futex operations are still on the backlog. |
💯. Thanks Ben, I really appreciate you taking a run at it. As you already know, #486 (unfortunately) blocks on the |
The pi-aware futex operations are now available in the Skip-ahead 17627 build. |
Confirmed the OP test case passes, which is more than good enough for me. Anything falling into the "priorities are not currently a supported WSL feature so there are limitations" caveat should be filed under a different cover. Thanks for squashing this. |
So there is a fix for this now? Thank goodness! I use WSL to do some simple audio-related operations and having sound is pretty much required for that. I've been rolling back the Fall Creators' Update for too many days now. |
PulseAudio bug # 106581. |
Doing this as a PulseAudio bug is around two years too late. It will be another two years before such a "fix" finds its way into an Ubuntu LTS. If we knew |
Closing this bug since the OP ask is now fixed. Please open a new bug if you hit any additional issues. Thanks! |
When will this fix make it to a non-insider version of Windows? Is it October? |
Yes. And yes some time in October but no guarantees in life. This goes for anything else marked as fixininsiderbuilds as well; which is one purpose of the tag. |
Might as well file this one too. This first came up in #486 which (naturally) isn't getting a lot of love over on User Voice. Besides PA, the construct also rears its head in a large popular software package here. Turns out that
lock_impl_posix.cc
ends up in a library that is in turn used by the gn meta build system. Which, if you close your eyes, you could frame as a CLI development use case.Build 14905 fails with:
pthread_mutexattr_init: Operation not supported
. I made some minor mods from the original so it compiles cleanly.gcc -o mutex_priority mutex_priority.c -pthread
The text was updated successfully, but these errors were encountered: