<?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 limits.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>cc8d04f4 - Remove need for explicit `Config::async_support` knob  (#12371)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs#cc8d04f4</link>
        <description>Remove need for explicit `Config::async_support` knob  (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling &quot;old async&quot; and&quot;new async&quot; in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is &quot;locked&quot; during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to &quot;new async&quot; support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as &quot;this thing requires `async` stuffinternally.&quot; This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can&apos;t simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it&apos;s required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a &quot;requires async&quot; boolean stored within it.* All configuration options which end up requiring async, such as  yielding with epochs, turn this boolean on.* Creation of host functions which use async  (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is  disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it&apos;s not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that&apos;s required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That&apos;s leftfor future refactorings however.prtest:full* Review comments* Fix CI failures

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs</description>
        <pubDate>Fri, 23 Jan 2026 02:46:45 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs#96e19700</link>
        <description>Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs</description>
        <pubDate>Wed, 07 Jan 2026 17:08:11 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>5f7cf53e - Make table growth a true `async fn` (#11442)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs#5f7cf53e</link>
        <description>Make table growth a true `async fn` (#11442)* Make table growth a true `async fn`Upon further refactoring and thinking about #11430 I&apos;ve realized that wemight be able to sidestep `T: Send` on the store entirely which would bequite the boon if it can be pulled off. The realization I had is thatthe main reason for this was `&amp;mut dyn VMStore` on the stack, but thatitself is actually a bug in Wasmtime (#11178) and shouldn&apos;t be done.The functions which have this on the stack should actually ONLY have theresource limiter, if configured. This means that while the`ResourceLimiter{,Async}` traits need a `Send` supertrait that&apos;srelatively easy to add without much impact. My hunch is that plumbingthis through to the end will enable all the benefits of #11430 withoutrequiring adding `T: Send` to the store.This commit starts out on this journey by making table growth a true`async fn`. A new internal type is added to represent a store&apos;s limiterwhich is plumbed to growth functions. This represents a hierarchy ofborrows that look like:* `StoreInner&lt;T&gt;`  * `StoreResourceLimiter&lt;&apos;_&gt;`  * `StoreOpaque`    * `Pin&lt;&amp;mut Instance&gt;`      * `&amp;mut vm::Table`This notably, safely, allows operating on `vm::Table` with a`StoreResourceLimiter` at the same time. This is exactly what&apos;s neededand prevents needing to have `&amp;mut dyn VMStore`, the previous argument,on the stack.This refactoring cleans up `unsafe` blocks in table growth rightnow which manually uses raw pointers to work around the borrow checker.No more now!I&apos;ll note as well that this is just an incremental step. What I plan ondoing next is handling other locations like memory growth, memoryallocation, and table allocation. Each of those will require furtherrefactorings to ensure that things like GC are correctly accounted forso they&apos;re going to be split into separate PRs. Functionally though thisPR should have no impact other than a fiber is no longer required for`Table::grow_async`.* Remove #[cfg] gate

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs</description>
        <pubDate>Mon, 18 Aug 2025 18:03:38 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>df69b9a7 - Implement the table64 extension to the memory64 proposal (#9206)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs#df69b9a7</link>
        <description>Implement the table64 extension to the memory64 proposal (#9206)This commit implements the table64 extention in both Wasmtime andCranelift.Most of the work was changing a bunch of u32 values to u64/usize.The decisions were made in align with the PR #3153 whichimplemented the memory64 propsal itself.One significant change was the introduction of `IndexType`and `Limits` which streamline and unify the handling of limitsfor both memories and tables.The spec and fuzzing tests related to table64 are re-enabled whichprovides a good coverage of the feature.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs</description>
        <pubDate>Wed, 11 Sep 2024 17:34:31 +0000</pubDate>
        <dc:creator>Linwei Shang &lt;github@lwshang.com&gt;</dc:creator>
    </item>
<item>
        <title>1512a954 - Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs#1512a954</link>
        <description>Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)* Add `anyhow` stuff to our internal `wasmtime` crate preludeWe use it basically everywhere and it is annoying to have to import.I also did an audit of existing `use` statements and removed the now-redundantones and replaced one-off imports with usage of the prelude, so that the preludeis available by default in more places.* Fix `cargo doc`

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs</description>
        <pubDate>Fri, 14 Jun 2024 15:24:12 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs#81a89169</link>
        <description>Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime&apos;s platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren&apos;t implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime&apos;s TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the &quot;custom&quot; platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can&apos;t be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn&apos;t enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime&apos;s `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs</description>
        <pubDate>Sat, 04 May 2024 22:02:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>d4242001 - Support compilation-only build by adding a `runtime` feature (#7766)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs#d4242001</link>
        <description>Support compilation-only build by adding a `runtime` feature (#7766)* Add `runtime` feature to `wasmtime` crateThis feature can be disabled to build `wasmtime` only for compilation.This can be useful when cross-compiling, especially on a target thatcan&apos;t run wasmtime itself (e.g. `wasm32`).* prtest:full* don&apos;t round pages without runtime feature* fix async assertions* move profiling into runtime* enable runtime for wasmtime-wasi* enable runtime for c-api* fix build_artifacts in non-cache case* fix miri extensions* enable runtime for wast* enable runtime for explorer* support cranelift all-arch on wasm32* add doc links for `WeakEngine`* simplify lib runtime cfgs* move limits and resources to runtime* move stack to runtime* move coredump and debug to runtime* add runtime to coredump and async features* add wasm32 build job* combine engine modules* single compile mod* remove allow for macro paths* add comments

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/limits.rs</description>
        <pubDate>Mon, 29 Jan 2024 15:51:43 +0000</pubDate>
        <dc:creator>Adam Bratschi-Kaye &lt;adam.bratschikaye@dfinity.org&gt;</dc:creator>
    </item>
</channel>
</rss>
