clarify "WebWorkers are expensive" statement

[wanderview]

Sorry, to nitpick, but the README has a bit of FUD here:

WebWorkers are expensive (~5MB per thread)

Workers can be expensive, but this is largely a factor of how much time browser vendors have invested in making them fast/lightweight. For example, a minimal worker on gecko takes ~1.5MB and a MB of that is purely based on the GC nursery configuration. There is a lot of room to make workers memory efficient.

Flat statements like this, though, discourage use and that in turn discourages browser vendors from investing time to improve them. Please clarify it in some way. "WebWorkers can be expensive in some browsers", etc.

[surma]

I weakened the statement and made it Chrome-specific in 3a8e459.

We’ll try to gather some more numbers on this across browsers.

[wanderview]

Thanks! Sorry for stomping all over your your twitter mentions.

[surma]

@wanderview Now that the WICG discussion has quieted down a bit, I was wondering if your concerns have been addresses or if we need to talk about this some more.

You are right that if we spent time on it, we could probably make WebWorkers more (memory-)efficient. However, I envision Tasklets (or whatever they end up being) to be one of the core tools of web app development, so apps will probably end up loading multiple tasklets per app. As a result, I think it’s essential that tasklets can share an OS thread. Especially for mobile.

As stated in my most recent post:

If we take your [AshleyScirra’s] suggestion of extending WebWorkers to allow multiple cross-origin WebWorkers to share an OS thread, it becomes easy for one worker to starve out all the other’s by accident by using APIs like Synchronous XHR. So I think we should disallow them – which already makes them different from the “old” WebWorkers. Starvation is still possible, but less likely to happen by accident. Also, WebWorkers still only have postMessage() as a way to communicate[...]. Additionally, things like a WebWorker being a EventTarget is not possible.

What I am trying to say: Tasklets are effectively WebWorkers with the added capability of sharing an OS thread. But the proposal also includes the (necessary) measures to cover the consequences of that change. Additionally, there’s a convenience layer (i.e. proxy classes) so that off-thread work becomes a no-brainer.

Please let me know any reservations you might have. Eager to work this out with you :)

[wanderview]

AFAIK web worker spec doesn't say anything about how Workers are mapped to OS threads. I believe Presto even went so far as to implement them as cooperative threads on top of the main thread. I don't think there is anything stopping a browser from implementing some kind of M:N scheduling model.

I guess it would be helpful to see some examples where we expected tasklets to behave better than workers and an explanation of why. Right now I don't understand why all of this can't be implemented in workers in the browser with some library API sugar.

[drufball]

Thanks for this feedback! I think we can definitely try to pull together a demo implementation on top of Workers to get a sense for the cost. Before starting on that, I just want to make sure we know what numbers we're looking to see:

• Memory / performance overhead of user-land + workers impl on all browsers
• Size of user-land library
• Expected improvements from worklets

Does that look right, or are there numbers I'm missing? What kind of delta do you think would be convincing for trying the tasklets approach?

[wanderview]

I think it would be helpful to have a mapping like:

"Spec detail X in Tasklets leads to browser optimization Y that is not possible with Workers because of Z."

At least for myself this is what I feel is missing to make this more compelling than a syntactic improvement.

[annevk]

Workers are pretty much required to have their own thread these days due to them being agents (see SharedArrayBuffer objects et al).

Would a tasklet not be able to share SharedArrayBuffer objects with other agents?

[wanderview]

Workers are pretty much required to have their own thread these days due to them being agents (see SharedArrayBuffer objects et al).

Can you explain this? Some WASM folks have been mentioning the possibility of pinning workers with SAB to a single core in some cases. This would seem to suggest that SAB workers do not need to explicitly map to a separate OS thread.

[annevk]

See the requirements in https://tc39.github.io/ecma262/#sec-agent-clusters and the next section. An agent needs to be able to make forward progress and pausing it is not allowed if you don't also pause all other agents in the cluster. I think that ends up disallowing cooperative threading and schedule-based models.

[jyasskin]

@annevk I don't think that use of SharedArrayBuffer requires that the using thread have the forward-progress guarantees that Agent provides. In ECMAScript's view of the world, the Tasklet has to run inside some Agent, but it doesn't have to be a whole Agent by itself. Am I missing something?

I do believe that "a browser needs at least as many OS threads as it has workers, but it can get away with fewer OS threads than tasklets" is correct and the kind of optimization @wanderview is asking for, but I'm not certain.

Edit: The above was a statement about Worklets rather than Tasklets. For Tasklets as currently proposed, I think the semantic model is that tasklet.addModule(x) posts a message to a single Window-global Worker to ask it to add the module, and then all modules share that Worker's event loop.

[annevk]

@jyasskin that might be accurate if a tasklet doesn't have its own event loop, similar to a window. But in that case you might be able to observe cross-origin tasklets on the same agent through timing side channels?

[jyasskin]

@annevk Augh, I was talking about Worklets rather than Tasklets. I've updated my previous comment to talk about Tasklets instead. We should make sure the security considerations mention the potential timing side-channels.

[surma]

I think the semantic model is that tasklet.addModule(x) posts a message to a single Window-global Worker to ask it to add the module, and then all modules share that Worker's event loop.

No, that’s just how the polyfill works. Tasklets are worklets.