Stream: git-wasmtime

Topic: wasmtime / issue #12809 Epoch interruption of memory.atom...


view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 09:13):

Destructor17 opened issue #12809:

Feature

Epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. So it would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I'm believe there is no need to try to do the same with fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty of program that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, SO memory.atomic.wait* would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 09:15):

Destructor17 edited issue #12809:

Feature

Epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. So it would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I believe there is no need to try to do the same with fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty of program that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, SO memory.atomic.wait* would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 09:16):

Destructor17 edited issue #12809:

Feature

Epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. So it would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I believe there is no need to try to do the same for fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty of program that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, so memory.atomic.wait* instructions would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 09:17):

Destructor17 edited issue #12809:

Feature

Currently epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. It would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I believe there is no need to try to do the same for fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty of program that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, so memory.atomic.wait* instructions would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 09:29):

Destructor17 edited issue #12809:

Feature

Currently epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. It would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I believe there is no need to try to do the same for fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty of program that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, so memory.atomic.wait* instructions would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 09:49):

Destructor17 edited issue #12809:

Feature

Currently epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. It would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I believe there is no need to try to do the same for fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty of program that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, so memory.atomic.wait* instructions would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 09:51):

Destructor17 edited issue #12809:

Feature

Currently epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. It would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I believe there is no need to try to do the same for fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty for programs that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, so memory.atomic.wait* instructions would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2026 at 12:26):

Destructor17 edited issue #12809:

Feature

Currently epoch interruption has no effect on memory.atomic.wait* instructions since they just block and give no opportunity for epoch checking to occur. It would be nice to make threads work with epoch interruption.

Benefit

Being able to interrupt threads that stale on waiting for something to happen on another thread.

I'm personally interested in being able to do the following with programs targeting wasip1-threads:

Implementation

I believe this problem can be solved by doing the following:

This is what I initially tried to do on my own, but wasmtime-internal-cranelift crate scared me a bit, so I guess it is better to be done by someone who knows what to do.

I believe there is no need to try to do the same for fuel consumption.

Alternatives

Alternative 1. Almost the same can be done by transforming WASM. Same loop, but timeout is limited to, let's say, 10 ms. Not sure when to break that loop. It comes with huge performance penalty for programs that spawn lots of stale threads.

Alternative 2. Notify all waits on all shared memories without doing any changes, probably multiple times, so memory.atomic.wait* instructions would simply return 0 (Ok). May break some logic in guest code, so it is suitable only for terminating.

Alternative 3. That loop, as well as checking for epoch, can be implemented on the host side, but I don't know how to access current epoch value from there.


Last updated: Mar 23 2026 at 16:19 UTC