Revisiting the edge-case semantics of wake

Bắt đầu bằng cách đọc ngữ nghĩa wake hiện tại và đề xuất trong issue này, sau đó xem lại WebAssembly/threads#72 và tài liệu tham chiếu ECMAScript Atomics.wake được liên kết. Kiểm tra các ghi chú lịch sử của các cuộc thăm dò CG để xem các quyết định trước đây. Công việc được xem là hoàn tất khi có một cách giải quyết ngữ nghĩa đã được thống nhất và các cập nhật đặc tả tương ứng, nhưng issue này không nêu tệp triển khai hay bài kiểm thử nào.

Currently

The current semantics of wake is as follows:

Wake consumes two operands, an i32 address, and an i32 wake count.

The wake count operand is interpreted as a signed value, and the following behaviour occurs based on this value:

Let num woken be the number of threads woken by this operation.

The result of the wake operation is num woken if num woken can be represented as an i32, and trap otherwise.

Proposal

I propose instead to interpret the wake count operand as an unsigned value, with the following behaviour

The result of the wake operation is num woken, which is guaranteed to be representable as an i32.

Reasoning

From discussions in TPAC and elsewhere (https://github.com/WebAssembly/threads/issues/72), there were concerns about the behaviour of the operation when the number of waiting threads is greater than UINT32_MAX. There was also some concern about conformity to JS, but this seems to be a red herring as JS takes a float to represent its wake count, waking all threads if passed ∞, and otherwise clamping the value to max(ToInteger wake count, 0) with no concern for the UINT32_MAX edge-case (link).

Consider that if there really are more than UINT32_MAX waiting threads, neither implementation can wake all of them in one operation (must use a loop), the former because it would trigger a trap, and the latter because the number to wake is not representable.

Polls in previous CGs appear very inconclusive, and focussed on i32 vs i64 representation. I don't have a strong opinion on the representation issue, but I think adding a trap case to the semantics isn't the right approach, and interpreting the num waker argument as signed is slightly rogue.

This all seems to be perfectly theoretical anyway. At least on linux, superficial googling suggests that there are several internal limits that restrict maximum thread numbers to the order of millions, even on 64-bit systems, with a very hard limit of 2^29 due to their implementation of PIDs. Several linux syscalls assume that the number of waiters can be represented using i32. There's also a blogpost on experimentally pushing the envelope in Windows which doesn't get anywhere near 2^32.

This hopefully means that the semantic change won't break anything, as a negative wake count argument will now be interpreted as a ginormous positive one (at least 2^31).