Revisiting the edge-case semantics of wake

Inizia leggendo la semantica attuale di wake e la proposta in questa issue, quindi esamina WebAssembly/threads#72 e il riferimento collegato a ECMAScript Atomics.wake. Controlla le note storiche dei sondaggi del CG per le decisioni precedenti. Il lavoro sarà considerato completato quando saranno disponibili una risoluzione semantica concordata e i corrispondenti aggiornamenti della specifica, ma questa issue non indica file di implementazione né test.

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).