Interrupting long-running code

[s3ththompson]

Have we considered the feasibility of embedders (specifically the browser) being able to interrupt long-running wasm code to return responsiveness to the main thread?

In JavaScript I believe the unresponsive script dialog is triggered after a certain amount of time (5-10 seconds) of continuous execution.

[lukewagner]

Although I there was some recent discussion on specing this to a greater degree, I believe that the interruption of long-running JS is not addressed by the specs and is in the same supernatural category of events as OOM-killing or browser crash. For FF, we were planning to have the same interrupt behavior for wasm as JS since there is nothing really JS-specific about it.

[sunfishcode]

It's difficult to spec this directly because the spec otherwise has no units of time. However, it'd still be great for browsers to be roughly compatible. Perhaps we could add an informal recommendation to Web.md for the JS behavior here; anyone want to take this on?

[taisel]

Would the threading model interfere? Namely apply the limitations of the Atomics API being specced for TC39 onto WASM? There was some chatter about deadlocking main thread and thus gimping locks for it.

I don't think an API for interrupting threads should be defined as it would be a huge challenge with thread synchronization etc. Rather the embedder should just be able to abort the entire process if it wishes, all threads, all resources. If code needs to be able to abort loops etc then it should have the burden of checking it's own flags on loop iterations etc and for synchronizing this.

[taisel]

Comment earlier was about detecting "long-running code." Specifically, deadlock being a lack of activity rather than an infinite loop.

[s3ththompson]

Agreed that this is also an interesting question for the deadlock case. IMO the browser should provide a good user experience here...

[pizlonator]

I tend to think we should leave this out of the spec because I don't see much upside to mandating or recommending anything in particular. I'm not aware of the differences in how ES implementations handle this hurting apps or creating compat problems.

-Filip

On Jul 18, 2016, at 10:11 AM, Seth Thompson notifications@github.com wrote:

Agreed that this is also an interesting question for the deadlock case. IMO the browser should provide a good user experience here...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[flagxor]

With wasm running on a worker / wasm thread I could see that we'd maybe want some guarantees that things won't get killed. But for the main thread, leaving things up to implementors seems fine.

[pizlonator]

On Jul 19, 2016, at 11:24 AM, Brad Nelson notifications@github.com wrote:

With wasm running on a worker / wasm thread I could see that we'd maybe want some guarantees that things won't get killed.

Can you elaborate?

-Filip

But for the main thread, leaving things up to implementors seems fine.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #712 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ALnOO-2j8KfaO8qyDymuJ9HIumt_CkStks5qXRZigaJpZM4I77AR.

[lukewagner]

In particular, I think it's hard to make any such guarantees when browsers have to consider the user closing a tab, the process getting OOM-killed, terminate() from the parent, etc. I think this is a shared concern between both wasm and JS and better addressed in terms of existing work on SAB, agents and clusters since I think they're just two sides of the same coin.

[pizlonator]

Agreed.

-Filip

On Jul 19, 2016, at 12:40 PM, Luke Wagner notifications@github.com wrote:

In particular, I think it's hard to make any such guarantees when browsers have to consider the user closing a tab, the process getting OOM-killed, terminate() from the parent, etc. I think this is a shared concern between both wasm and JS and better addressed in terms of existing work on SAB, agents and clusters http://tc39.github.io/ecmascript_sharedmem/shmem.html#ExecutableCodeAndContexts.AgentCluster since I think they're just two sides of the same coin.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #712 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ALnOO4uadgLN4B70nv4UdVTETK9Gi6Ziks5qXShAgaJpZM4I77AR.

[lars-t-hansen]

FWIW, the SAB proposal does not have a signaling mechanism but has some language around forced agent termination, specifying that if an agent is killed (not simply interrupted) by the implementation then either (a) there exists some reliable way of notifying the agent cluster of the termination or (b) the entire cluster must be killed. Whether this requirement will survive, and whether it will be honored by the browsers, I can't say. (Currently all browsers do (b), in practice.)

I considered adding a signaling API but it seemed like overkill for SAB's MVP.

All of this is pretty weak, but bear in mind that until now, ECMAScript hasn't even had a notion of introspecting on an agent since the only agent would be the one doing the introspection. DOM, on its side, provides workers but no introspection API (and very weak semantics). For SAB, the most natural way to add a signaling mechanism would be to add it to the worker API along with some kind of introspection on workers. For Wasm, it depends on what "threads" end up being.

[jfbastien]