Skip to content

Conversation

@glbrntt
Copy link
Contributor

@glbrntt glbrntt commented Nov 25, 2025

Motivation:

The various 'withMumbleContinuation' APIs are supposed to be invoked synchronously with the caller. This assumption allows a lock to be acquired before the call and released from the body of the 'withMumbleContinuation' after e.g. storing the continuation. However this isn't the case and the job may be re-enqueued on the executor meaning that this is pattern is vulnerable to deadlocks.

Modifications:

  • Drop and reacquire the lock in Promise
  • Avoid resuming continuations while holding the lock

Result:

Lower chance of deadlock

Motivation:

The various 'withMumbleContinuation' APIs are supposed to be invoked
synchronously with the caller. This assumption allows a lock to be
acquired before the call and released from the body of the
'withMumbleContinuation' after e.g. storing the continuation. However
this isn't the case and the job may be re-enqueued on the executor
meaning that this is pattern is vulnerable to deadlocks.

Modifications:

- Drop and reacquire the lock in Promise
- Avoid resuming continuations while holding the lock

Result:

Lower chance of deadlock
@glbrntt glbrntt added the 🔨 semver/patch No public API change. label Nov 25, 2025
@Lukasa Lukasa enabled auto-merge (squash) November 25, 2025 08:47
@Lukasa Lukasa merged commit 48d7c83 into apple:main Nov 25, 2025
47 checks passed
@glbrntt glbrntt deleted the continuation branch November 25, 2025 08:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🔨 semver/patch No public API change.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants