Clarify global (shared?) state

[jeffposnick]

I've found that wrapping your head around global state tends to be a problem for developers who are using service workers for the first time. (C.f. https://stackoverflow.com/questions/38835273/when-does-code-in-a-service-worker-outside-of-an-event-handler-run)

You cover this a little bit, with the idea of explaining the lifetime of a tasklet and also a hypothetical callback to save (and also load?) state, but I think it's worth getting in front of that as a potential source of confusion.

Here's a question that I have about the hypothetical behavior after reading the spec:

// tasklet.js
let count = 0;
export function increment() {
  return count++;
}

// app.js
const tasklet1 = await tasklet.addModule('tasklet.js');
const tasklet2 = await tasklet.addModule('tasklet.js');

 // This will log 0.
console.log(await tasklet1.increment());

 // This will.. also log 0? Or 1?
console.log(await tasklet2.increment());

// Will this always log 1 (or 2)? What if a lot of time has
// passed and tasklet1 was killed?
console.log(await tasklet1.increment());

[surma]

Good question. In my head, each addModule call instantiates a new tasklet that has it’s own scope. There is no sharing of state whatsoever between tasklets. That means your example would log 0, 0, 1.

@bfgeek WDYT?

Either way, whatever we conclude, I’ll add to the explainer.

[jakearchibald]

You could go the other way here and never guarantee state:

const tasklet1 = await tasklet.addModule('tasklet.js');

// This will log 0.
console.log(await tasklet1.increment());

// This will log 0.
console.log(await tasklet1.increment());

If we can guarantee that calls to a tasklet always behave as if they were just instantiated, the browser decide per call what thread the run on.

// Each call may run on different threads.
tasklet1.doSomething();
tasklet1.doSomethingElse();

This only makes sense if the fresh-state-guarantee can be done efficiently, and global state isn't needed.

[surma]

I like the idea of enforcing to not rely on global scope. It would allow us to parallelize as needed in the future without having to worry about breaking existing code.

However, I worry it will make adoption of tasklets much harder. Developers won’t be able to re-use existing code as it is unprecedented behavior. Would we advocate to use IndexedDB to persist data across calls instead? Tasklets would also not be able to keep references to main-thread objects if we decide to support that.

Bottom line: I am leaning towards having a global scope per tasklet.

@domenic would love to hear your thoughts on this.

[domenic]

From what I recall of talking with @bfgeek it sounds like in general native platforms have only one background thread per app. In that case sharing the global it seems fine.

Note that enforcing multiple global scopes is expensive: it gives the overhead of a whole new JS engine instance, essentially, to every tasklet. That seems to push away from using a separate tasklet or tasklet module for each part of your app.