<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in interrupt.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>9ce3ffe1 - Update some CI dependencies (#7983)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#9ce3ffe1</link>
        <description>Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Thu, 22 Feb 2024 23:54:03 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>b0939f66 - Remove explicit `S` type parameters (#5275)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#b0939f66</link>
        <description>Remove explicit `S` type parameters (#5275)* Remove explicit `S` type parametersThis commit removes the explicit `S` type parameter on `Func::typed` and`Instance::get_typed_func`. Historical versions of Rust required thatthis be a type parameter but recent rustcs support a mixture of explicittype parameters and `impl Trait`. This removes, at callsites, asuperfluous `, _` argument which otherwise never needs specification.* Fix mdbook examples

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Wed, 16 Nov 2022 05:04:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>2afaac51 - Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#2afaac51</link>
        <description>Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)* Return `anyhow::Error` from host functions instead of `Trap`This commit refactors how errors are modeled when returned from hostfunctions and additionally refactors how custom errors work with `Trap`.At a high level functions in Wasmtime that previously worked with`Result&lt;T, Trap&gt;` now work with `Result&lt;T&gt;` instead where the error is`anyhow::Error`. This includes functions such as:* Host-defined functions in a `Linker&lt;T&gt;`* `TypedFunc::call`* Host-related callbacks like call hooksErrors are now modeled primarily as `anyhow::Error` throughout Wasmtime.This subsequently removes the need for `Trap` to have the ability torepresent all host-defined errors as it previously did. Consequently the`From` implementations for any error into a `Trap` have been removedhere and the only embedder-defined way to create a `Trap` is to use`Trap::new` with a custom string.After this commit the distinction between a `Trap` and a host error isthe wasm backtrace that it contains. Previously all errors in hostfunctions would flow through a `Trap` and get a wasm backtrace attachedto them, but now this only happens if a `Trap` itself is created meaningthat arbitrary host-defined errors flowing from a host import to theother side won&apos;t get backtraces attached. Some internals of Wasmtimeitself were updated or preserved to use `Trap::new` to capture abacktrace where it seemed useful, such as when fuel runs out.The main motivation for this commit is that it now enables hosts tothread a concrete error type from a host function all the way through towhere a wasm function was invoked. Previously this could not be donesince the host error was wrapped in a `Trap` that didn&apos;t provide theability to get at the internals.A consequence of this commit is that when a host error is returned thatisn&apos;t a `Trap` we&apos;ll capture a backtrace and then won&apos;t have a `Trap` toattach it to. To avoid losing the contextual information this commituses the `Error::context` method to attach the backtrace as contextualinformation to ensure that the backtrace is itself not lost.This is a breaking change for likely all users of Wasmtime, but it&apos;shoped to be a relatively minor change to workaround. Most use cases canlikely change `-&gt; Result&lt;T, Trap&gt;` to `-&gt; Result&lt;T&gt;` and otherwiseexplicit creation of a `Trap` is largely no longer necessary.* Fix some doc links* add some tests and make a backtrace type public (#55)* Trap: avoid a trailing newline in the Display implwhich in turn ends up with three newlines between the end of thebacktrace and the `Caused by` in the anyhow Debug impl* make BacktraceContext pub, and add tests showing downcasting behavior of anyhow::Error to traps or backtraces* Remove now-unnecesary `Trap` downcasts in `Linker::module`* Fix test output expectations* Remove `Trap::i32_exit`This commit removes special-handling in the `wasmtime::Trap` type forthe i32 exit code required by WASI. This is now instead modeled as aspecific `I32Exit` error type in the `wasmtime-wasi` crate which isreturned by the `proc_exit` hostcall. Embedders which previously testedfor i32 exits now downcast to the `I32Exit` value.* Remove the `Trap::new` constructorThis commit removes the ability to create a trap with an arbitrary errormessage. The purpose of this commit is to continue the prior trend ofleaning into the `anyhow::Error` type instead of trying to recreate itwith `Trap`. A subsequent simplification to `Trap` after this commit isthat `Trap` will simply be an `enum` of trap codes with no extrainformation. This commit is doubly-motivated by the desire to always usethe new `BacktraceContext` type instead of sometimes using that andsometimes using `Trap`.Most of the changes here were around updating `Trap::new` calls to`bail!` calls instead. Tests which assert particular error messagesadditionally often needed to use the `:?` formatter instead of the `{}`formatter because the prior formats the whole `anyhow::Error` and thelatter only formats the top-most error, which now contains thebacktrace.* Merge `Trap` and `TrapCode`With prior refactorings there&apos;s no more need for `Trap` to be opaque orotherwise contain a backtrace. This commit parse down `Trap` to simplyan `enum` which was the old `TrapCode`. All various tests and such wereupdated to handle this.The main consequence of this commit is that all errors have a`BacktraceContext` context attached to them. This unfortunately meansthat the backtrace is printed first before the error message or trapcode, but given all the prior simplifications that seems worth it atthis time.* Rename `BacktraceContext` to `WasmBacktrace`This feels like a better name given how this has turned out, andadditionally this commit removes having both `WasmBacktrace` and`BacktraceContext`.* Soup up documentation for errors and traps* Fix build of the C APICo-authored-by: Pat Hickey &lt;pat@moreproductive.org&gt;

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Wed, 02 Nov 2022 16:29:31 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>52524d25 - Expose `TrapCode::Interrupt` on epoch based interruption (#4105)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#52524d25</link>
        <description>Expose `TrapCode::Interrupt` on epoch based interruption (#4105)

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Tue, 10 May 2022 15:27:30 +0000</pubDate>
        <dc:creator>Sa&#250;l Cabrera &lt;saulecabrera@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>c22033bf - Delete historical interruptable support in Wasmtime (#3925)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#c22033bf</link>
        <description>Delete historical interruptable support in Wasmtime (#3925)* Delete historical interruptable support in WasmtimeThis commit removes the `Config::interruptable` configuration along withthe `InterruptHandle` type from the `wasmtime` crate. The originalsupport for adding interruption to WebAssembly was added pretty early onin the history of Wasmtime when there was no other method to prevent aninfinite loop from the host. Nowadays, however, there are alternativemethods for interruption such as fuel or epoch-based interruption.One of the major downsides of `Config::interruptable` is that even whenit&apos;s not enabled it forces an atomic swap to happen when enteringWebAssembly code. This technically could be a non-atomic swap if theconfiguration option isn&apos;t enabled but that produces even more branch-ycode on entry into WebAssembly which is already something we try tooptimize. Calling into WebAssembly is on the order of a dozens ofnanoseconds at this time and an atomic swap, even uncontended, can addup to 5ns on some platforms.The main goal of this PR is to remove this atomic swap on entry intoWebAssembly. This is done by removing the `Config::interruptable` fieldentirely, moving all existing consumers to epochs instead which aresuitable for the same purposes. This means that the stack overflow checkis no longer entangled with the interruption check and perhaps one daywe could continue to optimize that further as well.Some consequences of this change are:* Epochs are now the only method of remote-thread interruption.* There are no more Wasmtime traps that produces the `Interrupted` trap  code, although we may wish to move future traps to this so I left it  in place.* The C API support for interrupt handles was also removed and bindings  for epoch methods were added.* Function-entry checks for interruption are a tiny bit less efficient  since one check is performed for the stack limit and a second is  performed for the epoch as opposed to the `Config::interruptable`  style of bundling the stack limit and the interrupt check in one. It&apos;s  expected though that this is likely to not really be measurable.* The old `VMInterrupts` structure is renamed to `VMRuntimeLimits`.

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Mon, 14 Mar 2022 20:25:11 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>7a1b7cdf - Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#7a1b7cdf</link>
        <description>Implement RFC 11: Redesigning Wasmtime&apos;s APIs (#2897)Implement Wasmtime&apos;s new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it&apos;s best to read the RFC thread and the PR thread.

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Thu, 03 Jun 2021 14:10:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>2697a18d - Redo the statically typed `Func` API (#2719)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#2697a18d</link>
        <description>Redo the statically typed `Func` API (#2719)* Redo the statically typed `Func` APIThis commit reimplements the `Func` API with respect to statically typeddispatch. Previously `Func` had a `getN` and `getN_async` family ofmethods which were implemented for 0 to 16 parameters. The return valueof these functions was an `impl Fn(..)` closure with the appropriateparameters and return values.There are a number of downsides with this approach that have becomeapparent over time:* The addition of `*_async` doubled the API surface area (which is quite  large here due to one-method-per-number-of-parameters).* The [documentation of `Func`][old-docs] are quite verbose and feel  &quot;polluted&quot; with all these getters, making it harder to understand the  other methods that can be used to interact with a `Func`.* These methods unconditionally pay the cost of returning an owned `impl  Fn` with a `&apos;static` lifetime. While cheap, this is still paying the  cost for cloning the `Store` effectively and moving data into the  closed-over environment.* Storage of the return value into a struct, for example, always  requires `Box`-ing the returned closure since it otherwise cannot be  named.* Recently I had the desire to implement an &quot;unchecked&quot; path for  invoking wasm where you unsafely assert the type signature of a wasm  function. Doing this with today&apos;s scheme would require doubling  (again) the API surface area for both async and synchronous calls,  further polluting the documentation.The main benefit of the previous scheme is that by returning a `impl Fn`it was quite easy and ergonomic to actually invoke the function. Inpractice, though, examples would often have something akin to`.get0::&lt;()&gt;()?()?` which is a lot of things to interpret all at once.Note that `get0` means &quot;0 parameters&quot; yet a type parameter is passed.There&apos;s also a double function invocation which looks like a lot ofcharacters all lined up in a row.Overall, I think that the previous design is starting to show too manycracks and deserves a rewrite. This commit is that rewrite.The new design in this commit is to delete the `getN{,_async}` family offunctions and instead have a new API:    impl Func {        fn typed&lt;P, R&gt;(&amp;self) -&gt; Result&lt;&amp;Typed&lt;P, R&gt;&gt;;    }    impl Typed&lt;P, R&gt; {        fn call(&amp;self, params: P) -&gt; Result&lt;R, Trap&gt;;        async fn call_async(&amp;self, params: P) -&gt; Result&lt;R, Trap&gt;;    }This should entirely replace the current scheme, albeit by slightlylosing ergonomics use cases. The idea behind the API is that theexistence of `Typed&lt;P, R&gt;` is a &quot;proof&quot; that the underlying functiontakes `P` and returns `R`. The `Func::typed` method peforms a runtimetype-check to ensure that types all match up, and if successful you geta `Typed` value. Otherwise an error is returned.Once you have a `Typed` then, like `Func`, you can either `call` or`call_async`. The difference with a `Typed`, however, is that theparams/results are statically known and hence these calls can be muchmore efficient.This is a much smaller API surface area from before and should greatlysimplify the `Func` documentation. There&apos;s still a problem where`Func::wrapN_async` produces a lot of functions to document, but that&apos;snow the sole offender. It&apos;s a nice benefit that thestatically-typed-async verisons are now expressed with an `async`function rather than a function-returning-a-future which makes it bothmore efficient and easier to understand.The type `P` and `R` are intended to either be bare types (e.g. `i32`)or tuples of any length (including 0). At this time `R` is only allowedto be `()` or a bare `i32`-style type because multi-value is notsupported with a native ABI (yet). The `P`, however, can be any size oftuples of parameters. This is also where some ergonomics are lostbecause instead of `f(1, 2)` you now have to write `f.call((1, 2))`(note the double-parens). Similarly `f()` becomes `f.call(())`.Overall I feel that this is a better tradeoff than before. While notuniversally better due to the loss in ergonomics I feel that this designis much more flexible in terms of what you can do with the return valueand also understanding the API surface area (just less to take in).[old-docs]: https://docs.rs/wasmtime/0.24.0/wasmtime/struct.Func.html#method.get0* Rename Typed to TypedFunc* Implement multi-value returns through `Func::typed`* Fix examples in docs* Fix some more errors* More test fixes* Rebasing and adding `get_typed_func`* Updating tests* Fix typo* More doc tweaks* Tweak visibility on `Func::invoke`* Fix tests again

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Thu, 11 Mar 2021 20:43:34 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>54c07d8f - Implement shared host functions. (#2625)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#54c07d8f</link>
        <description>Implement shared host functions. (#2625)* Implement defining host functions at the Config level.This commit introduces defining host functions at the `Config` rather than with`Func` tied to a `Store`.The intention here is to enable a host to define all of the functions oncewith a `Config` and then use a `Linker` (or directly with`Store::get_host_func`) to use the functions when instantiating a module.This should help improve the performance of use cases where a `Store` isshort-lived and redefining the functions at every module instantiation is anoticeable performance hit.This commit adds `add_to_config` to the code generation for Wasmtime&apos;s `Wasi`type.The new method adds the WASI functions to the given config as host functions.This commit adds context functions to `Store`: `get` to get a context of aparticular type and `set` to set the context on the store.For safety, `set` cannot replace an existing context value of the same type.`Wasi::set_context` was added to set the WASI context for a `Store` when using`Wasi::add_to_config`.* Add `Config::define_host_func_async`.* Make config &quot;async&quot; rather than store.This commit moves the concept of &quot;async-ness&quot; to `Config` rather than `Store`.Note: this is a breaking API change for anyone that&apos;s already adopted the newasync support in Wasmtime.Now `Config::new_async` is used to create an &quot;async&quot; config and any `Store`associated with that config is inherently &quot;async&quot;.This is needed for async shared host functions to have some sanity check during theirexecution (async host functions, like &quot;async&quot; `Func`, need to be called withthe &quot;async&quot; variants).* Update async function tests to smoke async shared host functions.This commit updates the async function tests to also smoke the shared hostfunctions, plus `Func::wrap0_async`.This also changes the &quot;wrap async&quot; method names on `Config` to`wrap$N_host_func_async` to slightly better match what is on `Func`.* Move the instance allocator into `Engine`.This commit moves the instantiated instance allocator from `Config` into`Engine`.This makes certain settings in `Config` no longer order-dependent, which is how`Config` should ideally be.This also removes the confusing concept of the &quot;default&quot; instance allocator,instead opting to construct the on-demand instance allocator when needed.This does alter the semantics of the instance allocator as now each `Engine`gets its own instance allocator rather than sharing a single one between allengines created from a configuration.* Make `Engine::new` return `Result`.This is a breaking API change for anyone using `Engine::new`.As creating the pooling instance allocator may fail (likely cause is not enoughmemory for the provided limits), instead of panicking when creating an`Engine`, `Engine::new` now returns a `Result`.* Remove `Config::new_async`.This commit removes `Config::new_async` in favor of treating &quot;async support&quot; asany other setting on `Config`.The setting is `Config::async_support`.* Remove order dependency when defining async host functions in `Config`.This commit removes the order dependency where async support must be enabled onthe `Config` prior to defining async host functions.The check is now delayed to when an `Engine` is created from the config.* Update WASI example to use shared `Wasi::add_to_config`.This commit updates the WASI example to use `Wasi::add_to_config`.As only a single store and instance are used in the example, it has no semanticdifference from the previous example, but the intention is to steer userstowards defining WASI on the config and only using `Wasi::add_to_linker` whenmore explicit scoping of the WASI context is required.

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Thu, 11 Mar 2021 16:14:03 +0000</pubDate>
        <dc:creator>Peter Huene &lt;peter@huene.dev&gt;</dc:creator>
    </item>
<item>
        <title>15c68f2c - Disconnects `Store` state fields from `Compiler` (#1761)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#15c68f2c</link>
        <description>Disconnects `Store` state fields from `Compiler` (#1761)*  Moves CodeMemory, VMInterrupts and SignatureRegistry from Compiler*  CompiledModule holds CodeMemory and GdbJitImageRegistration*  Store keeps track of its JIT code*  Makes &quot;jit_int.rs&quot; stuff Send+Sync*  Adds the threads example.

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Tue, 02 Jun 2020 18:44:39 +0000</pubDate>
        <dc:creator>Yury Delendik &lt;ydelendik@mozilla.com&gt;</dc:creator>
    </item>
<item>
        <title>0b3b9c29 - impl From&lt;anyhow::Error&gt; for Trap (#1753)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#0b3b9c29</link>
        <description>impl From&lt;anyhow::Error&gt; for Trap (#1753)* From&lt;anyhow::Error&gt; for Trap* Add TrapReason::Error* wasmtime: Improve Error to Trap conversion* Remove Trap::message

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Fri, 29 May 2020 20:24:12 +0000</pubDate>
        <dc:creator>Leonardo Yvens &lt;leoyvens@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>c9a0ba81 - Implement interrupting wasm code, reimplement stack overflow (#1490)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/examples/interrupt.rs#c9a0ba81</link>
        <description>Implement interrupting wasm code, reimplement stack overflow (#1490)* Implement interrupting wasm code, reimplement stack overflowThis commit is a relatively large change for wasmtime with two maingoals:* Primarily this enables interrupting executing wasm code with a trap,  preventing infinite loops in wasm code. Note that resumption of the  wasm code is not a goal of this commit.* Additionally this commit reimplements how we handle stack overflow to  ensure that host functions always have a reasonable amount of stack to  run on. This fixes an issue where we might longjmp out of a host  function, skipping destructors.Lots of various odds and ends end up falling out in this commit once thetwo goals above were implemented. The strategy for implementing this wasalso lifted from Spidermonkey and existing functionality inside ofCranelift. I&apos;ve tried to write up thorough documentation of how this allworks in `crates/environ/src/cranelift.rs` where gnarly-ish bits are.A brief summary of how this works is that each function and each loopheader now checks to see if they&apos;re interrupted. Interrupts and thestack overflow check are actually folded into one now, where functionheaders check to see if they&apos;ve run out of stack and the sentinel valueused to indicate an interrupt, checked in loop headers, tricks functionsinto thinking they&apos;re out of stack. An interrupt is basically justwriting a value to a location which is read by JIT code.When interrupts are delivered and what triggers them has been left up toembedders of the `wasmtime` crate. The `wasmtime::Store` type has amethod to acquire an `InterruptHandle`, where `InterruptHandle` is a`Send` and `Sync` type which can travel to other threads (or perhapseven a signal handler) to get notified from. It&apos;s intended that thisprovides a good degree of flexibility when interrupting wasm code. Notethough that this does have a large caveat where interrupts don&apos;t workwhen you&apos;re interrupting host code, so if you&apos;ve got a host importblocking for a long time an interrupt won&apos;t actually be received untilthe wasm starts running again.Some fallout included from this change is:* Unix signal handlers are no longer registered with `SA_ONSTACK`.  Instead they run on the native stack the thread was already using.  This is possible since stack overflow isn&apos;t handled by hitting the  guard page, but rather it&apos;s explicitly checked for in wasm now. Native  stack overflow will continue to abort the process as usual.* Unix sigaltstack management is now no longer necessary since we don&apos;t  use it any more.* Windows no longer has any need to reset guard pages since we no longer  try to recover from faults on guard pages.* On all targets probestack intrinsics are disabled since we use a  different mechanism for catching stack overflow.* The C API has been updated with interrupts handles. An example has  also been added which shows off how to interrupt a module.Closes #139Closes #860Closes #900* Update comment about magical interrupt value* Store stack limit as a global value, not a closure* Run rustfmt* Handle review comments* Add a comment about SA_ONSTACK* Use `usize` for type of `INTERRUPTED`* Parse human-readable durations* Bring back sigaltstack handlingAllows libstd to print out stack overflow on failure still.* Add parsing and emission of stack limit-via-preamble* Fix new example for new apis* Fix host segfault test in release mode* Fix new doc example

            List of files:
            /wasmtime-44.0.1/examples/interrupt.rs</description>
        <pubDate>Tue, 21 Apr 2020 18:03:28 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
