Move sleep slicing from musl's `__wait` to the lower level `emscripten_futex_wait`. NFC by sbc100 · Pull Request #26471 · emscripten-core/emscripten

sbc100 · 2026-03-17T19:49:34Z

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 · 2026-03-18T18:00:00Z

system/lib/pthread/library_pthread.c

-  double max_ms_slice_to_sleep = emscripten_is_main_runtime_thread() ? 1 : 100;
+  // Break up sleeping so that we process proxied work at regular intervals.
+  // TODO(sbc): This should be remove and/or moved down into
+  // `emscripten_futex_wait`.


@tlively do you think we can just remove this loop? i.e. to background threads actually want to be be running proxied work when they call emscripten_thread_sleep?

I'm not sure. It looks like the ProxyWorker used by the WasmFS OPFS backend does not need this: https://github.com/emscripten-core/emscripten/blob/main/system/lib/wasmfs/thread_utils.h#L67. I don't know about all the users of the system proxying queue, though.

Oh, what about dlopen? Will that depend on sleeping threads waking up to perform loading work?

No, the dlopen handling is done down in emscripten_futex_wait at the entry and exit from the wait.

The contract is that you can sleep as long as you want, as long you syncronize your loaded code as soon as you wake up.

i.e. a thread that is "sleeping" is considered "up-to-date" from the POV of the "sync-the-world" algorithm.

kripken · 2026-03-18T23:29:47Z

system/lib/libc/musl/src/thread/__wait.c

-	double max_ms_slice_to_sleep = is_runtime_thread ? 1 : 100;
-
-	while (*addr==val) {
-		if (is_runtime_thread || pthread_self()->cancelasync == PTHREAD_CANCEL_ASYNCHRONOUS) {


I get the second removal here (cancellation) but what about is_runtime_thread?

I moved that down into emscripten_futex_wait too.

See the comment that starts 1. We are the main runtime thread.

system/lib/pthread/emscripten_futex_wait.c

sbc100 · 2026-03-18T23:30:22Z

@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 · 2026-03-19T17:37:08Z

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.

tlively · 2026-03-19T20:42:09Z

system/lib/pthread/emscripten_futex_wait.c

+  // 1. We are the main runtime thread.  In this case we need to be able to
+  //    process proxied events from workers.  Note that this is not always
+  //    the same as being the main browser thread.  For example, when running
+  //    under node or when launching and emscripten-built program in a Web


Suggested change

// under node or when launching and emscripten-built program in a Web

// under node or when launching an emscripten-built program in a Web

tlively · 2026-03-19T20:42:33Z

system/lib/pthread/emscripten_futex_wait.c

+  //    process proxied events from workers.  Note that this is not always
+  //    the same as being the main browser thread.  For example, when running
+  //    under node or when launching and emscripten-built program in a Web
+  //    Worker.  This this case we limit our wait slices to 1ms intervals.


Suggested change

// Worker. This this case we limit our wait slices to 1ms intervals.

// Worker. In this case we limit our wait slices to 1ms intervals.

tlively · 2026-03-19T20:43:50Z

system/lib/pthread/library_pthread.c

-  double max_ms_slice_to_sleep = emscripten_is_main_runtime_thread() ? 1 : 100;
+  // Break up sleeping so that we process proxied work at regular intervals.
+  // TODO(sbc): This should be remove and/or moved down into
+  // `emscripten_futex_wait`.


Oh, what about dlopen? Will that depend on sleeping threads waking up to perform loading work?

…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 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 commented Mar 18, 2026

View reviewed changes

sbc100 requested review from dschuff and kripken March 18, 2026 18:03

sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from dc4a6db to c83cec6 Compare March 18, 2026 18:05

This was referenced Mar 18, 2026

Remove remaining pthread function from WASM_WORKERS build #26487

Open

Use C11 _Thread_local for current locale. NFC #26486

Merged

sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from c83cec6 to 56c46cb Compare March 18, 2026 23:25

kripken reviewed Mar 18, 2026

View reviewed changes

system/lib/pthread/emscripten_futex_wait.c Outdated Show resolved Hide resolved

sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from d025d13 to ee3f1b4 Compare March 19, 2026 17:36

sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from ee3f1b4 to dba24ed Compare March 19, 2026 17:37

tlively reviewed Mar 19, 2026

View reviewed changes

sbc100 force-pushed the handle_pthread_cancel_during_futext_wait branch from dba24ed to a44b167 Compare March 19, 2026 21:13

	// under node or when launching and emscripten-built program in a Web
	// under node or when launching an emscripten-built program in a Web

	// Worker. This this case we limit our wait slices to 1ms intervals.
	// Worker. In this case we limit our wait slices to 1ms intervals.

Conversation

sbc100 commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbc100 Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sbc100 commented Mar 18, 2026

Uh oh!

sbc100 commented Mar 19, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sbc100 commented Mar 17, 2026 •

edited

Loading

sbc100 Mar 19, 2026 •

edited

Loading