Accessing non-shared locals insides shared-barrier
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- wasm
- Domain
- operating-systems
Research direction
Start by reviewing the existing shared-barrier semantics and the initialization-tracking mechanism referenced in the issue. Compare the proposed explicit-initialization and implicit-default alternatives, then determine which behavior the proposal should specify and how it would apply to shared-suspendable and shared-fixed functions.
Written by the indexing model from the issue text.
Description
At the meeting today we discussed how it would be useful for shared-barrier to work like let and introduce new non-shared locals that could be accessed only inside the barrier block. However, let had a bunch of usability issues that caused us to discard it in favor of tracking the initialization state of non-nullable locals.
I realized that we could use the same strategy for non-shared locals inside shared-barrier blocks. Non-shared locals could be declared alongside other locals in shared-suspendable functions, but would not be accessible except inside shared-barrier blocks. They would start out as uninitialized at the beginning of each shared-barrier and would have to be explicitly initialized (potentially with null values) before they could be accessed. Alternatively, the beginning of the shared-barrier could implicitly set defaultable non-shared locals to their default values.
This seems to neatly solve the problem of accessing non-shared locals inside shared-barriers using only the existing mechanism of initialization tracking. It also eliminates one of the differences between shared-suspendable and shared-fixed functions by letting them declare the same kinds of locals, which seems nice.
- Dominant language
- WebAssembly
- Stars
- 97
- Forks
- 7
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/shared-everything-threads
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
WebAssembly/shared-everything-threads#119 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
WebAssembly/shared-everything-threads#114 · 7 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
WebAssembly/shared-everything-threads#105 · 6 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
WebAssembly/shared-everything-threads#99 · 5 comments ·
All issues in WebAssembly/shared-everything-threads
Similar issues
-
Console.printHexOpengood first issue kernel
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
JackFurton/who-would-build-a-kernel-in-java#33 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
topic-ctypes type-bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
python/cpython#158684 · 1 comment ·
Maintainers usually reply within 1 day
-
Hermes mounts list activation-hidden skills and installer staging rootsPossibly taken @Frun1na claimed this today. Opencomponent:skillfs
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
agentic-os-org/ANOLISA#4609 · 1 comment ·
Maintainers usually reply within 1 day
-
bug code-review gpu LOW windows
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day