Windows thread support: Part 1#2231
Conversation
a8f777b to
ecdcbd0
Compare
|
Whoops, I messed up the rebase at first. |
oli-obk
left a comment
There was a problem hiding this comment.
You need to run ./miri bless, too, in order to update the .stderr files. You may have to run this for multiple targets to make sure they're all in sync in their behaviour
|
If it helps, here are some public resources on |
…hrisDenton Fix compat_fn option method on miri This change is required to make `WaitOnAddress` work with rust-lang/miri#2231
|
I've rewritten the handle implementation based on what is actually guaranteed by the windows docs |
…hrisDenton Fix compat_fn option method on miri This change is required to make `WaitOnAddress` work with rust-lang/miri#2231
To the extent that these are relevant for this new code in Miri, please add links to them in comments in the code. :) |
|
☔ The latest upstream changes (presumably #2236) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Thanks for the PR! Looks like Windows is starting to catch up with our Linux support. :) I am working on a review, but in the future it'd be helpful to break PRs into smaller chunks. For example, I think this could have started with just thread spawning and joining, without all the concurrency primitives. Smaller PRs are a lot easier to review so any effort you can put into splitting a change into chunks is much appreciated. |
RalfJung
left a comment
There was a problem hiding this comment.
This looks great overall, very nice!
I hope all the new code you added is actually covered by tests. For thread spawning and the synchronization primitives, I would think the existing sync tests are enough, though I do not know if the stdlib actually uses these primitives.
I did not see a test that would join on a thread with a timeout, so that will have to be added (or the code for that be removed again). Also there are no new failing tests, which is a bit of a concern given that the pthreads primitives have a lot of failing tests to ensure that misuse of the pthread APIs is detected.
|
☔ The latest upstream changes (presumably #2332) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Looking at your commits, I see "basic threading" and "condvar, parking and yielding" are separate commits. If you could split those into separate PRs, that would help a lot with reviewing. Basically the first PR just needs to get |
8a6c1f8 to
f010307
Compare
|
@rustbot ready |
|
Just two more comment nits, then we are good to go. :) Since review is done, please squash the commits together a bit. |
|
@rustbot author |
|
☔ The latest upstream changes (presumably #2492) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@rustbot ready |
|
Awesome, thanks a ton for all your work and patience. :) @bors r+ |
|
☀️ Test successful - checks-actions |
Fix compat_fn option method on miri This change is required to make `WaitOnAddress` work with rust-lang/miri#2231
Implement condvars for Windows Adds 3 shims for Windows: `SleepConditionVariableSRW`, `WakeConditionVariable`, `WakeAllConditionVariable` to add support for condvars (which fixes rust-lang#2628). Salvaged from what was removed from rust-lang#2231
|
|
||
| // XXX HACK: This is how miri represents the handle for thread 0. | ||
| // This value can be "legitimately" obtained by using `GetCurrentThread` with `DuplicateHandle` | ||
| // but miri does not implement `DuplicateHandle` yet. |
There was a problem hiding this comment.
FWIW by now we do support DuplicateHandle so we could fix this. However that function has so many flags, I can't figure out how it would be used.^^
(Also I don't understand why we even need it, couldn't we just use GetCurrentThread directly?)
There was a problem hiding this comment.
GetCurrentThread returns a pseudo-handle, not a handle to the current thread. If the inner thread waited on that handle, it would actually wait on itself and not the main thread.
There was a problem hiding this comment.
I think the correct call would be DuplicateHandle(GetCurrentProcess(), GetCurrentThread(), GetCurrentProcess(), <out ptr>, 0, false, DUPLICATE_SAME_ACCESS).
There was a problem hiding this comment.
So DuplicateHandle doesn't duplicate that pseudo-handle, it performs a kind of normalization?
What an API...
There was a problem hiding this comment.
Well, it creates a new handle from it that actually needs to be closed. Pseudo-handles are like constant sentinel values really.
I have just spotted that the current miri impl incorrectly passes pseudo-handles straight through though, instead of throwing an unsup error. I think I'll need to work on a PR for that and this test
This PR adds support for threads on Windows.