Andreas Rossberg

I haven't followed the SIMD proposal closely, but using uN might indeed make sense there. But it depends on whether there always is enough context in the binary grammar to...

Yep.

@lukewagner: > There is a longer-term plan to add thread-creation operators to core wasm, but, for various connected reasons, this will take a while because it ends up requiring not...

@lukewagner, it's simpler actually: the same operator you describe plus a separate instantiate instruction. Because the spawned function must not be allowed to access non-shared state of its module, all...

@titzer, you don't even need first-class instances, only first-class memories, tables, globals, such that the `instantiate` instruction directly maps imports to exports. Not high priority, but probably significantly easier than...

@lukewagner: > When you say "the same operator you describe", do you mean the first version of thread.create I described, which takes a funcref or funcidx? Yep. In the paper...

@lukewagner, there might be use cases where a module has both shared and unshared exports. But the primary reason for putting the attribute on the function type is that we'd...

@lukewagner, my thinking was that if each function declares it anyway (as part of its type), then what's the use of *also* having a mode per module? Also, I always...

@AndrewScheidecker, silently duplicating state seems dangerous, since it can arbitrarily break state invariants the module is assuming. I think that should at least be gated by some third form of...

> It's not silent, it's controlled by whatever host API is being used to create threads. Sure, but the module itself has no way of controlling this and preventing a...