Stream: git-wasmtime

Topic: wasmtime / issue #2981 reset InterruptHandle

Wasmtime GitHub notifications bot (Jun 14 2021 at 14:21):

localvar opened issue #2981:

I need to interrupt the execution of user-provided wasm code if it cannot complete in a limited time, say 1 second.

The documentation of Interrupt says:

Interrupt interrupts currently executing WebAssembly code, if it's currently running, or interrupts wasm the next time it starts running.

So my question is: how to ensure it only interrupts the current execution but not the next?

For example:

go func() {
    time.Sleep(time.Second)
    interruptHandle.Interrupt()
} ()

// execute wasm code

As two goroutines are involved, there are race conditions, and it is possible for Interrupt to be called after the wasm code finishes current execution, which will result in the next execution be interrupted at the start.

There may be some tricky workarounds for this requirement, like execute a dummy wasm function to reset the Interrupthandle before execute the desired code, but all of them look ugly.

Is there a better way to reset the InterruptHandle?

Wasmtime GitHub notifications bot (Jun 14 2021 at 14:21):

alexcrichton commented on issue #2981:

I've transferred this issue to the wasmtime repository itself since the feature will need to be implemented here first.

Wasmtime GitHub notifications bot (Jun 14 2021 at 14:21):

alexcrichton labeled issue #2981:

I need to interrupt the execution of user-provided wasm code if it cannot complete in a limited time, say 1 second.

The documentation of Interrupt says:

Interrupt interrupts currently executing WebAssembly code, if it's currently running, or interrupts wasm the next time it starts running.

So my question is: how to ensure it only interrupts the current execution but not the next?

For example:

go func() {
    time.Sleep(time.Second)
    interruptHandle.Interrupt()
} ()

// execute wasm code

As two goroutines are involved, there are race conditions, and it is possible for Interrupt to be called after the wasm code finishes current execution, which will result in the next execution be interrupted at the start.

There may be some tricky workarounds for this requirement, like execute a dummy wasm function to reset the Interrupthandle before execute the desired code, but all of them look ugly.

Is there a better way to reset the InterruptHandle?

Wasmtime GitHub notifications bot (Jun 14 2021 at 14:21):

github-actions[bot] commented on issue #2981:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (May 04 2022 at 15:56):

alexcrichton commented on issue #2981:

This API has since been removed from Wasmtime so I'm going to close this

Wasmtime GitHub notifications bot (May 04 2022 at 15:56):

alexcrichton closed issue #2981:

I need to interrupt the execution of user-provided wasm code if it cannot complete in a limited time, say 1 second.

The documentation of Interrupt says:

Interrupt interrupts currently executing WebAssembly code, if it's currently running, or interrupts wasm the next time it starts running.

So my question is: how to ensure it only interrupts the current execution but not the next?

For example:

go func() {
    time.Sleep(time.Second)
    interruptHandle.Interrupt()
} ()

// execute wasm code

As two goroutines are involved, there are race conditions, and it is possible for Interrupt to be called after the wasm code finishes current execution, which will result in the next execution be interrupted at the start.

There may be some tricky workarounds for this requirement, like execute a dummy wasm function to reset the Interrupthandle before execute the desired code, but all of them look ugly.

Is there a better way to reset the InterruptHandle?

Last updated: Nov 22 2024 at 16:03 UTC