Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Introduce flag to prevent reallocation of shared memory

Đang mở
#173 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
wasm
Lĩnh vực
operating-systems

Hướng nghiên cứu

Issue không nêu tên các tệp trong repository, các bài kiểm thử hoặc các entry point của phần triển khai; hãy bắt đầu bằng việc xem xét đề xuất WebAssembly threads và các ví dụ khởi tạo shared memory trong báo cáo. Xác định xem một bộ nhớ đệm hoặc flag gắn với module có nằm trong phạm vi hay không, xác định vòng đời và ngữ nghĩa đóng gói của nó, đồng thời ghi lại các tiêu chí tương thích và xác thực trước khi triển khai.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Instantiating a module more than once allocates new memory for each instance, what if, instead, there could be a flag that would cause all instances to refer to the same memory?
Instead of them being thread-local memories, they would be "global."

This allows Wasm to remain completely self-contained, encapsulated, and in control of its own memory.
Currently, shared memory is completely useless if not importing host shared memory, but every step in between the module getting its memory, and the host passing it to the module, leaves room for mutation, and unexpected change at runtime, as the host has control over the array buffer too.

Nothing more would need to be changed, it would just change the lifetime of the memory.

This could be implemented as a simple cache associated with the module.

Current loading (JS):

// main.mjs:
const memory = new WebAssembly.Memory({ ..., shared: true });

const {
    instance,
    module
} = await WebAssembly.instantiateStreaming(..., ...memory...);

const thread = new Worker("./worker.mjs", ...);

worker.postMessage({ memory, module });

// worker.mjs:
... // await .postMessage({ memory, module })
const instance = await WebAssembly.instantiate(module, ...memory...);

With cached memory:

// main.mjs:
const {
    instance,
    module
} = await WebAssembly.instantiateStreaming(...);

const thread = new Worker("./worker.mjs", ...);

worker.postMessage(module);

// worker.mjs:
... // await .postMessage(memory)
const instance = await WebAssembly.instantiate(module);

In the former example, the WebAssembly module's memory may be corrupted later at the will of the host, breaking encapsulation, but the way that multi-threaded Wasm loading works, it leaves no alternative.

Would this break any of the core motivations/ideas/philosophies behind WebAssembly?

Ngôn ngữ chính
WebAssembly
Star
767
Fork
54
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của WebAssembly/threads

Tất cả issue của WebAssembly/threads

Issue tương tự

Thêm issue về Operating Systems

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.