Skip to content

Conversation

@TartanLlama
Copy link
Contributor

@TartanLlama TartanLlama commented Feb 11, 2026

This PR restructures the current two pthreads implementations into parallel directories to prepare for a third implementation for wasip3.

  • Move the single-threaded stubbed implementation from wasi-libc/thread-stub to wasi-libc/libc-top-half/musl/src/thread/single-threaded
  • Move the wasi-threads implementation from wasi-libc/libc-top-half/musl/src/thread to wasi-libc/libc-top-half/musl/src/thread/wasi-threads
  • Move common files into wasi-libc/libc-top-half/musl/src/thread/common
  • Delete the unused architecture subfolders from wasi-libc/libc-top-half/musl/src/thread

The implementation for wasip3 will live in wasi-libc/libc-top-half/musl/src/thread/coop-threads, which will be created and populated in future PRs.

@TartanLlama TartanLlama marked this pull request as ready for review February 11, 2026 13:19
@alexcrichton
Copy link
Collaborator

Thanks! My only hesitation here is how this will impact future updates of musl in wasi-libc. So far @sunfishcode has done all of those (I think), and my impression was that the current structure is organized as such to make this merging process easier. For example I thought the libc-top-half/musl directory was organized more-or-less as a submodule-of-sorts where libc-bottom-half contained all the custom-written code for wasi-libc. Personally I don't actually know how one would go about updating musl, though, so I don't know the impact this would have.

Given that, a few questions:

  • Is this required to be in the libc-top-half directory/build/etc to get access to musl-private headers or similar? Or could all the custom wasi code in theory be movable to libc-bottom-half? (trying to gauge if such a move is even possible)
  • @sunfishcode would you be able to weigh in on the affect this might have on future updates to musl? Or, alternatively, would you be willing to write up the steps you've taken historically to update musl?

@TartanLlama
Copy link
Contributor Author

Yeah, the pthreads impl relies a lot on the musl internals for the opaque pthreads struct. @sunfishcode and I chatted about this briefly last week and our conclusion was that, given the low volume of upstream musl updates, it seems more valuable to focus on the maintainability of wasi-libc as its own implementation than to optimize for ease of merging upstream patches.

For the coop threading implementation, I started off just ifdefing everywhere I needed changes, but it quickly became a bit of a mess for some of the more complex functions, and many of them just have entirely different implementations that would be living in the same files.

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.

2 participants