Linux futex (v1 and v2) API fixes, tests and Ziggification #23464
+402
−99
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Use `packed struct` for flags arguments. So, instead of
`linux.FUTEX.WAIT` use `.{ .cmd = .WAIT, .private = true }`
* rename `futex_wait` and `futex_wake` which didn't actually specify
wait/wake, as `futex_3arg` and `futex_4arg` (as its the number
of parameters that is different, the `op` is whatever is specified.
* expose the full six-arg flavor of the syscall (for some of the advanced
ops), and add packed structs for their arguments.
* Use a `packed union` to support the 4th parameter which is sometimes a
`timespec` pointer, and sometimes a `u32`.
* Add tests that make sure the structure layout is correct and that the
basic argument passing is working (no actual futexes are contended).
* `futex2_waitv` always takes a 64-bit timespec. Perhaps the `kernel_timespec` should be renamed `timespec64`? Its used in iouring, too. * Add `packed struct` for futex v2 flags and parameters. * Add very basic "tests" for the futex v2 syscalls (just to ensure the code compiles). * Update the stale or broken comments. (I could also just delete these they're not really documenting Zig-specific behavior.) Given that the futex2 APIs are not used by Zig's library (they're a bit too new), and the fact that these are very specialized syscalls, and they currently provide no benefit over the existing v1 API, I wonder if instead of fixing these up, we should just replace them with a stub that says 'use a 3rd party library'.
|
Hmm, not clear what's going on with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
linux: futex v1 API cleanup
Use Ziggish
packed structfor flags arguments. Old:linux.FUTEX.WAITvs new:.{ .cmd = .WAIT, .private = false }.rename
futex_waitandfutex_wakewhich didn't actually specify wait/wake, asfutex_3argandfutex_4arg(as its the number of parameters that is different, the actualopis the second parameter).provide the full six-arg flavor of the syscall (for some of the advanced ops), and add packed structs for the flag-ish parameters.
Use a
packed unionto support the 4th parameter which is sometimes atimespecpointer, and sometimes a 32-bit value.Add tests that make sure the structure layout is correct and that the basic argument passing is working (no actual futexes are contended).
linux: futex v2 API cleanup
futex2_waitvalways takes a 64-bit timespec. Perhaps thekernel_timespecshould be renamedtimespec64now? Its used in iouring, too.Add Ziggish
packed structencoding for futex v2 flag parameters.Add very basic "tests" for the futex v2 syscalls (these found the 64-bit timespec bug).
Update the stale or broken comments. (I could also just delete these they're not really documenting Zig-specific behavior.)
Given that the futex2 APIs are not used by Zig's library (they're a bit too new), and the fact that these are very specialized syscalls, and they currently provide no strong benefits over the existing v1 API, it might be prudent to just delete them entirely. If you're fancy enough to build stuff on the futex API, you're more than capable of writing your own syscall wrappers ...