Skip to content

Move sleep slicing from musl's __wait to the lower level emscripten_futex_wait. NFC#26471

Merged
sbc100 merged 1 commit intoemscripten-core:mainfrom
sbc100:handle_pthread_cancel_during_futext_wait
Mar 20, 2026
Merged

Move sleep slicing from musl's __wait to the lower level emscripten_futex_wait. NFC#26471
sbc100 merged 1 commit intoemscripten-core:mainfrom
sbc100:handle_pthread_cancel_during_futext_wait

Conversation

@sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Mar 17, 2026

This reduces the number of places we need to breaking up our wait operation. It also means that other users the emscripten_futex_wait API don't break pthread proxying or async cancellation.

This change removes one more place where we were erroneously calling pthread_self() in the Wasm Workers build of libc, so this change also makes the code less broken in the Wasm Worker case.

Needed as part of #26487

@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch 4 times, most recently from 65227c2 to dc4a6db Compare March 18, 2026 17:47
@sbc100 sbc100 requested review from dschuff and kripken March 18, 2026 18:03
@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from dc4a6db to c83cec6 Compare March 18, 2026 18:05
@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from c83cec6 to 56c46cb Compare March 18, 2026 23:25
@sbc100
Copy link
Collaborator Author

sbc100 commented Mar 18, 2026

@dschuff this is the next PR in the patch chain leading to #26487. (In fact is the last one). I hope I did an OK job describing the rational in the description. Let me know if anything is not clear here.

@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from d025d13 to ee3f1b4 Compare March 19, 2026 17:36
@sbc100
Copy link
Collaborator Author

sbc100 commented Mar 19, 2026

I had gemini CLI go over potentially issues with this PR and it found a few subtle issues with the slicing.. all of which are now fixed.

@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from ee3f1b4 to dba24ed Compare March 19, 2026 17:37
@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from dba24ed to a44b167 Compare March 19, 2026 21:13
@sbc100
Copy link
Collaborator Author

sbc100 commented Mar 20, 2026

I'd love to land this (and the followup #26487) today if possible. WDYT?

@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from a44b167 to 78b5c64 Compare March 20, 2026 18:45
@sbc100 sbc100 requested review from kripken and tlively March 20, 2026 19:59
…n_futex_wait`. NFC

This means we only need to do this breaking up on our `wait` operations
in a single place.  It also means that other users the
`emscripten_futex_wait` API don't break pthread proxying or async
cancellation.

The moved code is only included in pthread-enabled builds so should not
effect Wasm Workers builders.

This change also paves the way for enabling musl's `__wait` to work
with `WASM_WORKERS`.
@sbc100 sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from 78b5c64 to a2f1a06 Compare March 20, 2026 21:16
@sbc100 sbc100 merged commit d36e8bc into emscripten-core:main Mar 20, 2026
18 of 20 checks passed
@sbc100 sbc100 deleted the handle_pthread_cancel_during_futext_wait branch March 20, 2026 21:30
sbc100 added a commit that referenced this pull request Mar 20, 2026
Remove remaining pthread function from WASM_WORKERS build. NFC

This includes `pthread_self`, along with the internal `__get_tp`
function on which its bases.
These are not valid to call in Wasm Workers.

This PR is currently stacked on top of #26471
sbc100 added a commit to sbc100/emscripten that referenced this pull request Mar 20, 2026
This should have been part of emscripten-core#26471.

The breaking up of the wait time for 2 of the 3 cases that are handled
here is now handled one layer own in emscripten_futex_wait:

1. Breaking up the wait because we are the main runtime thread.
2. Breaking up the wait because we are async cancelable.

The third cases here (breaking up the wait because we are cancelable
in the non-async sense) still needs to be handled here at the higher
level.
sbc100 added a commit to sbc100/emscripten that referenced this pull request Mar 20, 2026
This should have been part of emscripten-core#26471.

The breaking up of the wait time for 2 of the 3 cases that are handled
here is now handled one layer own in emscripten_futex_wait:

1. Breaking up the wait because we are the main runtime thread.
2. Breaking up the wait because we are async cancelable.

The third cases here (breaking up the wait because we are cancelable
in the non-async sense) still needs to be handled here at the higher
level.
sbc100 added a commit to sbc100/emscripten that referenced this pull request Mar 21, 2026
This should have been part of emscripten-core#26471.

The breaking up of the wait time for 2 of the 3 cases that are handled
here is now handled one layer own in emscripten_futex_wait:

1. Breaking up the wait because we are the main runtime thread.
2. Breaking up the wait because we are async cancelable.

The third cases here (breaking up the wait because we are cancelable
in the non-async sense) still needs to be handled here at the higher
level.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants