fitzgen opened issue #6628:
That is, we should be able to reject allocation/instantiation for a component with more instances/tables/etc than a pre-configured limit, even when we actually have that much capacity in the pooling allocator.
fitzgen labeled issue #6628:
That is, we should be able to reject allocation/instantiation for a component with more instances/tables/etc than a pre-configured limit, even when we actually have that much capacity in the pooling allocator.
fitzgen labeled issue #6628:
That is, we should be able to reject allocation/instantiation for a component with more instances/tables/etc than a pre-configured limit, even when we actually have that much capacity in the pooling allocator.
fitzgen labeled issue #6628:
That is, we should be able to reject allocation/instantiation for a component with more instances/tables/etc than a pre-configured limit, even when we actually have that much capacity in the pooling allocator.
fitzgen commented on issue #6628:
This might exist in
InstancePre
, need to double check.
fitzgen commented on issue #6628:
Either way, we should have typed errors for when you try to instantiate a component that lets you determine whether instantiation failed because there is not enough capacity for the component currently, or because the component is statically above the configured per-component limits on tables/memories/etc.
alexcrichton commented on issue #6628:
Right now this exists for modules as
InstanceAllocator::validate
and I think the solution here is "just" adding a component version of that. Note though that this is a compile-time check as opposed to a instantiation-time check, so you'd never run into a situation where a component could never be instantiated due to its limits.That being said I think a descriptive error here is still good to have, since even if a component fits within the limits configured it can still fail to instantiate and it'd be good to understand why.
Last updated: Dec 23 2024 at 12:05 UTC