TC39 Structs and Shared Structs
2023-08-18
plaintext logs
prev next
source on github
20:36
<rbuckton>
If we end up having this concept of thread-local fields, or a thread-local [[Prototype]], do we actually need shared structs? Could we solve the same problem by introducing shared and fixed fields on a class instead? In other words, treat all non-shared fields as just thread-local fields, while having all fixed fields establish a fixed shape for an object, with the remaining non-fixed fields at the end?
20:39
<rbuckton>
I suppose you'd still need to indicate whether non-shared fields are "structured clone"-able.
20:43
<rbuckton>

And this could all be potentially handled via privileged decorators rather than keywords, i.e.:

@Shareable()
class Foo {
  @Shared()
  x;

  @Shared()
  y;

  @Copiable()
  data;

  @ThreadLocal()
  toString() { ... }
}
20:47
<shu>
rbuckton: the 'shared' modifier is not fully composable so i feel like we still need shared structs. not fully composable meaning, it doesn't make sense to have an object with some shared fields and some non-shared fields
20:48
<rbuckton>
The reason I brought this up is that we were actively discussing non-shared (i.e., "thread-local") fields in the last meeting.
20:49
<shu>
though i think my gut reaction is 'dislike' largely because it feels weird to me to have a property as fundamental as 'whether identity of instances of this class is preserved across threads' to be implied by the fields that it has
20:50
<shu>
am i understanding you right that you're thinking of something like, if a class C has any shared fields, it produces shared instances, and the non-shared fields are thread-local?
20:50
<shu>
otherwise it's not a shared thing, and all fields are "thread-local" but that's not really observable since it can't escape the thread
20:52
<shu>
i don't understand what the decorator notation above is doing
20:55
<rbuckton>
does it matter if identity is preserved across threads, if they have no way to compare the identity?
20:56
<shu>
it very much matters if identity is preserved across threads because that's how you observe how many allocations you've done...
20:56
<shu>
these aren't structural
20:56
<shu>
(how do you not observe identity without making these structural?)
20:56
<rbuckton>
I suppose it matters for worker.postMessage(obj); worker.postMessage(obj);, but within a single call to postMessage references are preserved during structured clone.
20:57
<shu>
like, if things round-trip, i want the same Map lookups to work etc
20:57
<rbuckton>
In any case, the class in the example above is explicitly marked as @Shareable() which would control the identity behavior.
20:58
<shu>
so far it feels like it comes down to taste, whether it feels nicer to have sharing semantics of fields and objects be determined "bottom up" by per-field annotations, or whether it's nicer to have sharing semantics be determined "top down" by per-class/struct annotations, with per-field annotations for exceptional cases (like thread-local)
20:58
<rbuckton>
All of the decorators serve the same purpose as a keyword might. There was a strong sentiment in the past by some committee members that once Decorators is at Stage 4 we should avoid adding new keywords for things if a decorator would suffice. While I'm not sure I 100% agree, decorators could be used for this.