Integrate a way to interrupt execution

[Pkcarreno]

Is your feature request related to a problem? Please describe.
When a long process is already running, and I want to make some changes in the code to execute again, I have to wait to the first execution end in order to execute the new code

Describe the solution you'd like
Using the already existing AbortController API could help, by passing a signal from an AbortController instance.

// declare an AbortController instance
const abortController = new AbortController();
const signal = abortController.signal;


//  pass AbortController signal to sandbox options
const sandboxOptions: SandboxOptions = {
    // ...
    signal
};

// anywhere where abortController instance exist
abortController.abort() // terminate execution inmediately

The idea is that when an abort signal is sent, the process fires a dispose() of the execution thread. I'm not fully sure if this is the right approach to end execution, but it worked for my previously

Describe alternatives you've considered
quickjs-emscripten-sync has a similar functionality, but it's implemented with a logic inherented from quickjs-emscripten

basically, you have ref variables with the arena instance and a quickjs's context instance

let arenaRef: Arena;
let contextRef: QuickJSContext;

//...

const context = await getQuickJS().then((deps) => {
        return deps.newContext();
 });
contextRef = context

// then:

const arena = new Arena(context);
 arenaRef = arena;

and then, any time you want to "end" execution, just dispose them

 arenaRef.dispose()
contextRef.dispose()

The main issue with this implementation is that you have to save a global ref of the instances. That's why I think the abortController approach is more clear

Additional context
I am remaking a web editor and having the ability to stop the execution, especially when there are promises to wait, is important to be able to finish the execution and run again quickly. I had already implemented this logic once before with quickjs-emscripten-sync and the dispose() function, but in this case I don't have as much control over the execution process, and I think this feature could help in other scenarios as well.

Btw, thanks a lot. This library simplify a lot the usage of quickjs-emscripten and already help me improve my project jsod by a lot (I will publish it in a few days)

[sebastianwessel]

Hey @Pkcarreno

Thanks for your feedback.

Controlling WebAssembly (WASM) execution from the host environment isn’t straightforward — especially when using the synchronous API. This is due to the nature of the runtime and the limited options available to interrupt or manage WASM execution from the outside.

In your case, I strongly recommend moving the execution into its own Web Worker, which can be controlled by the main thread. This approach prevents the main event loop from being blocked (which would freeze the UI) and gives you much better control over the execution.

For example, you could implement an “Abort” button that simply terminates the worker thread, stopping the execution entirely.

The main issue is that, while you can implement abort controller logic in theory, it doesn’t work reliably in practice — especially with synchronous WASM execution. The problem is that the event loop is blocked until the synchronous (WASM) call completes, making it nearly impossible to trigger the controller in time. Only timer-based mechanisms might still work, but interactive solutions like an “Abort” button won’t respond, as the UI thread is frozen.

This page explains the issue in more detail:
https://sebastianwessel.github.io/quickjs/docs/basic-understanding.html