rust-lang
Implement FreeBSD syscall _umtx_op for futex support
Links to #3553.
Currently This implements the WAIT and WAKE operations of the _umtx_op syscall.
Enable sync and concurrency tests in ci/ci.sh and add tests that calls _umtx_op directly.
Thanks for the PR! We have a significant backlog currently so unfortunately it could take a while until you get a proper review, sorry.
I have not yet changed ci/ci.sh because I don't exactly know which filters to pass. Currently if I test it locally only the the tests that use libc::cpuset_getaffinity fail.
You should add sync to have it test the libstd synchronization primitives.
Also, please add a test that directly calls the FreeBSD functions.
@rustbot author
Please post @rustbot ready when the PR is ready for the next round of review.
Those are not my commits, I hope I didn't do something wrong.
As for the changes, I:
- changed the handling of
uaddranduaddr2to now being correct - fixed/updated/added tests to correctly test behaviour of the syscall
- updated/added lots of extra comments explaining things or referring to the manual
Only thing that I can think of is problem with the Real Time clock that is used with timespec when running in isolation mode.
Yeah something is definitely wrong with the PR, I can't review it in this state. Please make sure only your commits are on this branch. Probably a rebase can fix this.
@rustbot author
I think i fixed it, only my commits are present on this branch
@rustbot ready
In the future, please avoid rebasing unless there are conflicts. Github is pretty bad at dealing with changes to the PR, and rebasing throws it off entirely, causing a bunch of extra work on my side.
Sorry ):, you said that a rebase would probably fix it, and it sort of did. I had never seen something like that before and could not find anything that resembled that. Hopefully it doesn't cause to much problems.
Sorry ):, you said that a rebase would probably fix it, and it sort of did. I had never seen something like that before and could not find anything that resembled that. Hopefully it doesn't cause to much problems.
Yeah you must have done a rebase or a merge first to even cause the problem that the rebase then fixed. That first step is what I referred to. :)
This looks great, thanks! Please squash the commits, then we can land this. Please use the --keep-base flag when squashing so that the force-push diff is easier to review. Then write @rustbot ready after you pushed the squashed PR.
@rustbot author
Sorry, I have never squashed commits before. And I don't want to break te history Again.
How do I do this correctly?
It should be something like git rebase --interactive --keep-base origin/master (you may have to replace origin by something else, that depends on how you named the remote that points to the upstream Miri repo). That will open an editor; change all but the first line to say "squash" instead of "pick", save and close. Another editor will show up where you can pick a reasonable commit message for the one remaining commit.
I learned something new about git today, I hope this is what you meant :).
@rustbot ready