Skip to content

[pull] swiftwasm from main #4643

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

Merged
merged 15 commits into from
Jun 13, 2022
Merged

[pull] swiftwasm from main #4643

merged 15 commits into from
Jun 13, 2022

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 13, 2022

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

eeckstein and others added 15 commits June 10, 2022 11:12
In case of a single-block location, the verification of store_borrow locations didn't work in all cases.
`syscall` and `read` were missing when `swift-threading-package=none`
As soon as the waiting task is successfully enqueued on the blocking
task, both tasks have to be considered invalidated because the
blocking task can concurrently complete and resume its waiters:

- The waiting task ensures that the blocking task is valid while
  it's waiting.  However, that's measured from the perspective of
  the waiting task, not from the perspective of the thread that was
  previously executing it.  As soon as the waiting task is resumed,
  the wait call completes and the validity guarantee on the blocking
  task disappears, so the blocking task must be treated as
  invalidated.

- The waiting task ensures that it is valid as long as it isn't
  complete.  Since it's trying to wait, it must not be complete.
  However, as soon we resume it, it can complete, so the waiting
  task must also be treated as invalidated.

This is one of those things that's not really easy to test, and the
need for a fix is pretty urgent, so I'm submitting this patch without
a test.  I'll try to land a race test that demonstrates the bug in
the next few days.

@kavon deserves all the credit here for some truly heroic debugging
and finally recognizing the flaw in the code; I'm just popping in
at the last minute to sheepishly patch the bug.

Fixes rdar://92666987
Make the following documentation changes:

* update last tested version number and emphasize that the process
  may work for later platform versions,

* update required packages to emphasize py3 instead of py2.7,

* python3 link is not strictly required to need root.

* update the suggested checkout config file to the stable branch used
  in the "upstream" checkout config file, and

* mention some extra flags are now required to properly switch off
  Dispatch (since without pr swiftlang/swift-corelibs-libdispatch#559
  Dispatch won't compile).

* reinforce building release by default, since the flags likely needed
  for debug builds aren't provided in the command snippet.
For some reason the second argument went missing.  Fix by adding it back.
…-wait-enqueueing

When waiting on a task, escalate it before enqueuing the waiting task
[Threading][Pthreads] Fix pthread_cond_wait() call.
…blean

Fix LoadBorrowImmutabilityChecker to handle reborrows
…gle-threaded-build

[stubs] include unistd.h to repair swift-threading-package=none build
…rification

Fix store borrow verification
@kateinoigakukun kateinoigakukun merged commit ca4a9f9 into swiftwasm Jun 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants