Skip to content

[thread-spawn] Fix TLS discussion #9

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.

Sign up for GitHub

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 2 commits into from
Jul 11, 2023
Merged

[thread-spawn] Fix TLS discussion #9

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e2bcdda
[thread-spawn] Fix TLS discussion
abrown Jul 10, 2023
01c61c7
review: list all objects, fix grammar
abrown Jul 11, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 12 additions & 8 deletions proposals/thread-spawn/Overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,8 +149,8 @@ paper for the sequential consistency guarantees). Following the paper, this prop

- `shared` tables will be grown and modified atomically
- `shared` globals will be modified atomically
- `shared` functions can only call other `shared` functions; any non-`shared` objects are
thread-local
- `shared` functions can never access non-`shared` objects; e.g., they only call other `shared`
functions and only access `shared` memories, tables, and globals

__TODO__: add a WAT example

Expand Down Expand Up @@ -213,12 +213,16 @@ This issue can be discussed further here: [Should we include

### What about thread-local storage (TLS)?

`shared` attributes partition the module's objects into two sets: `shared` and thread-local. Each
object (table, memory, global) that is not shared is initialized with its default values (e.g., a
memory has `data` entries) and any changes are only visible to the thread itself. These non-`shared`
objects can be used for thread-local storage. Alternately, one could use a specific section of
shared memory for TLS, as [wasi-libc][wasi-libc-tls] currently does for C's auxiliary stack.
`shared` attributes prevent `shared` functions from accessing any non-`shared` objects. This means
that TLS must be implemented by indexing a thread (see [TIDs]) into something `shared`, e.g., a
`shared` memory.

One might imagine splitting up tables or sets of globals for TLS, but `shared` memories are likely
more straightforward. For example, when compiling C/C++ to WebAssembly, address-taken local
variables are placed on an auxiliary stack in linear memory. For wasi-threads support, wasi-libc was
already modified [to understand][wasi-libc-tls] how to manage thread-local versions of this stack.

[TIDs]: #what-about-thread-ids-tids
[wasi-libc-tls]: https://github.com/WebAssembly/wasi-libc/blob/bd950eb128bff337153de217b11270f948d04bb4/libc-top-half/musl/src/thread/pthread_create.c#L456

__TODO__: how is this different than a new instance?
Expand Down Expand Up @@ -251,7 +255,7 @@ implemented via the existing `wait` and `notify` instructions.

### What about exiting a thread?

There are a couple of sides to this; recall that that "thread" here means a function invoked via
There are a couple of sides to this; recall that "thread" here means a function invoked via
`thread.spawn`:

1. If a thread is __finished__ (e.g., `return`), it simply ends. There is no caller to return to and
Expand Down