rbuckton: i applaud the scope of "shared modules" but i feel that is tantamount to designing a new language, which is not incremental and significantly increases risk of adoption or shipping anything.

put another way, IMO the only realistic way to move the needle for multithreading for JS is to have an opt-in carve out for shared memory. shared structs is that opt-in. to have "shared modules" seems to require the capability to write code that is actual parallel and threadsafe in general, including a threadsafe stdlib. were i to do a greenfield project i'd design a stdlib with that in mind but i feel like that would be too much to bite off at the moment?

more i think about it, i think the non-threadsafe stdlib thing is the actual showstopper for me

Basically Ron suggested an implicit shared cross agent registry, which is a non starter in my book.

(and I want this feature in my project I'm working on)

module blocks do not currently preserve their identity through structured cloning

if it's a string, you're dealing with module maps that may not resolve the same way between agents

module blocks is however my suggestion, and it doesn't solve the independent initialization use case. By definition one agent has to init first, and share the module block definition through postMessage, then agent 2 has to define the shared struct

The module map is agent specific, different agents may have a different module map. The main question is independent initialization and what happens when you receive a shared struct from another agent, whether there is a relation to the "same" shared struct that may have been declared in the local agent

I'm not so concerned about identity discontinuity. If each agent/realm is required to load its own copy of the behavior for a struct, the code defining that behavior could be different per agent/realm because of bundling/minification/tree shaking.

A and B may have subtly different implementations of Vector (due to tree shaking, etc.), so there needs to be some way for A and B to coordinate what a Vector is.

Right, but the main question is whether this should be possible without an explicit "synchronization" message between A and B

so, I guess the question is, whether we especially want to permit this difference

The tree shaking concern isn't conjecture either. If "the way" to do multithreading in JS is going to require duplicating runtime code in each thread, developers are going to want to find ways to minimize the memory footprint of short-lived threads by tree shaking away unused functionality.

Actually: I think it should work just fine to use a small module which just contains the field definitions, and then have other chunks of code (different in different workers/agents) which go back and install methods on the class.

How do you "attach" the behavior to a struct definition? What is the shared identity of the struct definition

Bundlers, minifiers, and treeshakers exist for a reason. Performance is important, so whatever solution we come up with must be able to handle web reality.

also using the module map would work

But the same problem exists in the main thread as well. We wouldn't be able to handle per-channel prototype associations either.

Except for bundling?

Module expressions require an explicit introduction however before defining the struct

Which means the struct value->prototype relationship must be per-thread.

yes this is a given at the outset of the conversation; I thought we've been talking in those terms this whole time

In this "use the global scope" idea, what happens if the registration changes, aka the global property gets redefined. Do existing objects have their proto automagically change to the new object ?

Skimming back really quick, but the ability to define modules that are evaluated when constructing a new realm is exactly what I'd want.

a proxy object is the definition of exotic

on the instances. Is the argument that we already have exotic behavior there so, exotic behavior on the prototype is ok?

It really feels like this pre-registration stuff really is realm "arguments". With preload or other generic realm init, you can only express the identity of a struct kind as a string in code, where if you had a way to pass arguments to that init logic, you could pass handles to the struct definitions.

// vector2d.js
// Each shared struct type, whether data only or "prepared" has its own unique type
export const vector2Dtype = SharedStructType.prepare(["x", "y"]);

const _Vector2D = SharedStructType.getConstructor(vector2Dtype);

// custom construction behavior
export function Vector2D(x = 0, y = 0) {
  const _this = Reflect.construct(_Vector2D, [], new.target);
  _this.x = x;
  _this.y = y;
  return _this;
}

// prototype methods
Vector2D.prototype.distanceTo = function (v) {
  const dx = this.x - v.x;
  const dy = this.y - v.y;
  return Math.sqrt(dx * dx + dy * dy);
};

SharedStructType.registerPrototype(vector2Dtype, Vector2D.prototype);

// main.js
import { Vector2D, vector2DType } from "./vector2d.js";
const v1 = new Vector2D(1, 2);
const worker = new Worker("worker.js");
worker.postMessage([vector2DType, v1]);

// worker.js
// worker imports Vector2D, which causes registration as a side-effect.
import { Vector2D, vector2DType } from "./vector2d.js";

const v2 = new Vector2D(3, 4);

parentPort.on("message", ([mainVector2DType, v1]) => {
  SharedStructType.registerPrototype(mainVector2DType, Vector2D.prototype);
  assert(mainVector2DType !== vector2DType);
  assert(
    SharedStructType.getConstructor(mainVector2DType) !==
      SharedStructType.getConstructor(vector2Dtype)
  );
  assert(v1 instanceof Vector2D); // by virtue of sharing a prototype
  v1.x; // 1
  v1.distanceTo(v2); // ok
  v1.toString(); // ok
});

SharedStructType.getConstructor() is needed to allow the program to avoid duplicating type definitions in each agent/realm. I think the burden of such deduplication should be on the program, not on the engine.

If the engine had to deduplicate itself, you'd either need a user provided type identifier at "prepare" time, and a global lock around such type definitions, or you'd need to somehow be able to collapse separate definitions into a single one. In either case you'd have to figure out what to do if the shape definition does not match, and in the case of definition collapse, how do you communicate the error to the program?

By having the type definition generate the unique type identifier, you avoid all those complications in the engine, at the cost of putting more type hydration burden on the program.

I don't see how it creates more potential for mistakes. it just moves the knowledge of string identifiers to the application layer