bytecodealliance / wasmtime-dotnet

.NET embedding of Wasmtime https://bytecodealliance.github.io/wasmtime-dotnet/
Apache License 2.0
409 stars 52 forks source link

Implemented `Store.SetLimits` #243

Closed martindevans closed 1 year ago

martindevans commented 1 year ago

Implemented Store.SetLimits using the new wasmtime_store_limiter function.

martindevans commented 1 year ago

I wasn't completely sure how to expose this method, due to the way limits are handled. Opinions?

Use -1 for default

This is what the C API expects, but it's a bit ugly.

Use nullable values and null for default

This I think fits C# better, but now leaves us accepting both -1 and null for defaults.

Hardcode default values

The documentation does specify exactly what the defaults are (unlimited or 10000). So we could hardcode those as the default values in the method signature. They're already effectively "hardcoded" in the documentation as is.

kpreisser commented 1 year ago

Thanks for creating this PR! I also thought about implementing this, but didn't find time to do so.

Opinions?

I would favor option 2 (use nullable values), at least for the parameters that can specify an unlimited value according to the documentation (memory_size and table_elements). This would match e.g. the Memory.Maximum API which is also a nullable long?, where null means the memory doesn't have a maximum.

Regarding accepting both negative values and null, we could throw an ArgumentOutOfRangeException if a negative value is specified, so that null is the only way to specify that the default value should be used.

What do you think? Thanks!

martindevans commented 1 year ago

Thanks for the feedback, I went back and made some changes.

memorySize, instances, tables and memories now all throw if a negative value is passed.

I noticed in the implementation that table_elements is handled differently (https://github.com/bytecodealliance/wasmtime/blob/ec6755512f7607c92a5dfd28bc8af782ee973ed6/crates/c-api/src/store.rs#L115) - it's cast down to a u32 internally. So I'm handling that differently (as uint?), which eliminates the need for a runtime check of that value (and also prevents passing values that are too large).

peterhuene commented 1 year ago

Thanks for implementing this!