Change 'incompletely specified behavior' phrasing to 'limited local nondeterminism' #141
Conversation
|
|
||
| WebAssembly is a [portable](Portability.md) sandboxed platform with limited, | ||
| local, nondeterminism. | ||
| * *limited* : non-deterministic execution can only occur in a small number of |
There was a problem hiding this comment.
apologies for an unimportant question, but was the space before : intentional here? (it would feel natural for me to not have it there, but maybe it's a style I'm not familiar with)
There was a problem hiding this comment.
You're right, it'd look better w/o space before.
| [Control Flow Integrity](http://research.microsoft.com/apps/pubs/default.aspx?id=64250). | ||
| * WebAssembly has no [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons). | ||
|
|
||
| Ideally, WebAssembly would be fully deterministic. Nondeterminism is only |
There was a problem hiding this comment.
Another probably unimportant note, it might be better to avoid saying "fully deterministic" because in a more general sense, there is or will be nondeterminism in wasm - stuff like calling a random number generator. Very nitpicky of course, as your intention is clear, so feel free to ignore.
There was a problem hiding this comment.
Haha, good point, I forgot about random. I can reword.
|
lgtm |
| Ideally, WebAssembly would be fully deterministic (except where nondeterminism | ||
| was introduced by the API, like `random` or input events). Nondeterminism is only | ||
| specified as a compromise when there is no other practical way to achieve | ||
| [portable](Portability.md), near-native performance. |
There was a problem hiding this comment.
Drop "near-"? We want native performance!
There was a problem hiding this comment.
I think "near-" is an acknowledgement that we are sandboxed and that we are providing a portability abstraction that discards certain unappetizing-but-nonetheless-expedient implementation details, and until we get hardware support there's always going to be some overhead. But ultimately it's a question of taste here.
There was a problem hiding this comment.
Yeah, this is just the conservative "don't overpromise" engineer in me, but "native" is probably fine here, so I'll take out "near-".
| - [Fixed-width SIMD may want some flexibility](EssentialPostMVPFeatures.md#fixed-width-simd) | ||
| - In SIMD.js, floating point values may or may not have subnormals flushed to zero. | ||
| - In SIMD.js, operations ending in "Approximation" return approximations that may vary between platforms. | ||
|
|
||
| - Environment-dependent resource limits may be exhausted |
|
lgtm after nit, and assuming you move the race/data stuff to another PR. |
|
Pulling this now-hidden note into the main discussion: So as @jfbastien pointed out, there are two levels of non-determinism here:
and 2 isn't really called out, so I think a further update is necessary. |
|
How about this? |
|
lgtm |
|
@sunfishcode too? |
|
|
||
| - [When threads are added as a feature](EssentialPostMVPFeatures.md#threads), | ||
| even without shared memory, nondeterminism will be visible through the | ||
| ordering of API calls. Shared memory will allow further nondeterminism via |
There was a problem hiding this comment.
I don't know if this is too pedantic, but it's also visible between API calls and WebAssembly program termination.
There was a problem hiding this comment.
True true, we must never forget termination.
…ename-incompletely-specified-behavior
…on nondeterminism of load
|
How about this? I couldn't think of how non-termination was visible except through APIs (like |
|
lgtm |
…d-behavior Change 'incompletely specified behavior' phrasing to 'limited local nondeterminism'
As discussed in #107.