3 ms·

Pardon my ignorance, but what if my JS was "for (;;) {}"? Can this handle heavy-CPU plugins? Maybe in a service/web worker? Part of the Realm API being a good u

Pardon my ignorance, but what if my JS was "for (;;) {}"? Can this handle heavy-CPU plugins? Maybe in a service/web worker? Part of the Realm API being a good use case for plugins I assume would include this kind of isolation but I admit to not having looked in detail.

EGreg 7y ago
I was searching for where they would talk about Realms handling infinite loops on the main JS thread but I didn’t see it. Have they tried WebWorkers? This seems like exactly the type of thing WebWorkers were designed for, instead of iframes. A background thread that can load arbitrary code in a sandbox and postMessage to send messages to the main thread. I remember looking into completely locking down the webworker to not even be able to make requests. It was possible! Just start a webworker from a sandboxed iframe. https://stackoverflow.com/questions/10653809/making-webworkers-a-safe-environment https://stackoverflow.com/questions/10653809/making-webworke... https://gist.github.com/pfrazee/8949363 https://gist.github.com/pfrazee/8949363 https://github.com/asvd/jailed https://github.com/asvd/jailed
- AgentME 7y ago
  A web worker would come with the downsides of their first iframe-based solution. (Web workers are basically iframes that have no visual portion and are guaranteed to run in a separate thread.)
rudi-c 7y ago
Excellent question! Being able to interrupt plugins would be nice, but it was a requirement we had to drop. Instead, we show UI that makes it clear that a plugin froze rather than Figma, in the hope that the user can understand. WebWorkers have the same issues as iframes where are basically like separate processes where data needs to be copied with message-passing. But if we had gone with the iframe approach, we’d consider sticking the plugin code inside a WebWorker inside the iframe.

3 ms·

Pardon my ignorance, but what if my JS was "for (;;) {}"? Can this handle heavy-CPU plugins? Maybe in a service/web worker? Part of the Realm API being a good u

by kodablah 7y ago

EGreg 7y ago
I was searching for where they would talk about Realms handling infinite loops on the main JS thread but I didn’t see it. Have they tried WebWorkers? This seems like exactly the type of thing WebWorkers were designed for, instead of iframes. A background thread that can load arbitrary code in a sandbox and postMessage to send messages to the main thread. I remember looking into completely locking down the webworker to not even be able to make requests. It was possible! Just start a webworker from a sandboxed iframe. https://stackoverflow.com/questions/10653809/making-webworkers-a-safe-environment https://stackoverflow.com/questions/10653809/making-webworke... https://gist.github.com/pfrazee/8949363 https://gist.github.com/pfrazee/8949363 https://github.com/asvd/jailed https://github.com/asvd/jailed
- AgentME 7y ago
  A web worker would come with the downsides of their first iframe-based solution. (Web workers are basically iframes that have no visual portion and are guaranteed to run in a separate thread.)
rudi-c 7y ago
Excellent question! Being able to interrupt plugins would be nice, but it was a requirement we had to drop. Instead, we show UI that makes it clear that a plugin froze rather than Figma, in the hope that the user can understand. WebWorkers have the same issues as iframes where are basically like separate processes where data needs to be copied with message-passing. But if we had gone with the iframe approach, we’d consider sticking the plugin code inside a WebWorker inside the iframe.