WebAssembly
Rename WebAssembly.Global to something
If a WebAssembly.Global represents what is, in effect, a thread-local variable, then it needs a better name. This is of course due to there being just one "thread" associated with a JavaScript context.
E.g. what about WebAssembly.Variable for a JS name?
We could as well rename the opcode (without changing its encoding), and there'd be no breaking change, other than to the text format.
Yes, we discussed this at the last CG meeting and agreed that the name should change. Sorry that I forgot about this.
I'm OK with Variable. I think we were calling them ThreadLocal in the meeting, but that was just to make it clear that they aren't actually global across threads.
"Variable" strikes me as a bit too unspecific. I'd prefer "XYGlobal", for some nice choice of XY (so that we leave the door open to also add YZGlobals of the non-TLS variety).
So the only reason that WebAssembly.Global is effectively thread-local is b/c it can't be shared between threads. But I think at some point in the future we could make Global shreable (in the same way as Memorym w/ a flag) and then it would be truly global.
But would we want to make a distinction between globals that are actually thread-local and globals that can be shared?
@lukewagner which is why I think it shouldn't include its scope in its name, since its scope depends on its usage.
@titzer, but the "global" refers to the lexical scope (as opposed to locals). Per-threadness is a different dimension.
Sorry, I didn't mean "scope" in the PL sense, should have used a different term. "Accessibility" is closer to what I meant.
Agree with @rossberg-chromium, I read "global" as w.r.t the module, and sharing between instances and/or threads is orthogonal.
On the other hand, "thread local" is a commonly-used term, so it'd be odd to use a WebAssembly.Global as thread-local storage.
Is a wasm runtime Module the unit of threading or can multiple of them belong to the same thread? Note: I specifically using "wasm runtime Mdoule" to differentiate using a linker to combile "wasm Modules" at compile time into a single "wasm runtime Module", I hope that makes sense?
On Tue, Jul 18, 2017 at 3:07 PM rossberg-chromium [email protected] wrote:
No ThreadLocalGlobal then? :) How about PerThreadGlobal?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WebAssembly/threads/issues/49#issuecomment-316212628, or mute the thread https://github.com/notifications/unsubscribe-auth/AA-hHGMqUCnNAaLuldkWF1RH7Qj5gUz7ks5sPSy3gaJpZM4OasD_ .
@winksaville, I suppose you mean a module instance?
If I understand your question correctly, then no, threads are orthogonal to module boundaries.
I always thought globals were scoped to the instance, not the thread. This distinction matters for non-JS implementations, where shared-memory threading can be a platform feature that WebAssembly gets for free.
We discussed this briefly at the CG meeting, but came to the conclusion that further bikeshedding should happen on the GH issue. :-}
@binji, any more bikeshedding from anyone?
The name 'global' is embedded pretty deeply elsewhere (text format, binary spec). IMO if we don't want WebAssembly.Global we should be prepared to fix those occurences too.
(I ask because I'm starting to implement this, and I'd prefer not to get into a situation where I have to do a massive renaming later...)
I haven't heard any, but maybe now that you've poked this thread there will be some more... :-)
I got the impression that folks were not happy with the name Global but disliked everything else more.
In the case of tables, memories and functions, the JS reflection's name matches the wasm core concept's name, so I really think we should stay consistent here and not invent something special.
We polled this in the Nov 28 CG meeting. I'll update with the specific numbers when I have them, but the consensus was to stay with WebAssembly.Global.
As I mentioned at meeting, there is also (non-cross-realm) global proposal to ECMAScript. It's on stage 3 now and it's blocked by some compatibility issues:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1325907
- https://bugzilla.mozilla.org/show_bug.cgi?id=1326032
- https://bugzilla.mozilla.org/show_bug.cgi?id=1328218
- https://bugs.webkit.org/show_bug.cgi?id=165171
If this proposal will land we'll have global.WebAssembly.Global name which looks weird (it's not necessary to add global. prefix though). I think we should discuss WebAssembly.Global name with TC39.
@chicoxyzzy, global as the standard name for the global object has been ruled out by TC39, because it would conflict with existing code. Either way, I don't think there would be any confusion.