Stream: git-wasmtime

Topic: wasmtime / Issue #1376 Support WASI snapshot0 in the C API.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 21 2020 at 00:10):

github-actions[bot] commented on Issue #1376:

Subscribe to Label Action

This issue or pull request has been labeled: "wasi", "wasmtime:c-api"

<details> <summary>Users Subscribed to "wasmtime:c-api"</summary>

</details>

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 21 2020 at 00:35):

peterhuene commented on Issue #1376:

Sigh. To get the shared (between the multiple WASI context builders) file handles working on Windows, we'd need to open with sharing options specifically on Windows.

I'm not really a big fan of this impl (i.e. having the multiple WASI instances). I may take another stab at this to fix #1220.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 21 2020 at 00:36):

peterhuene edited a comment on Issue #1376:

Sigh. To get the shared stdio (between the multiple WASI context builders) file handles working on Windows, we'd need to open with sharing options.

I'm not really a big fan of this impl (i.e. having the multiple WASI instances). I may take another stab at this to fix #1220.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 14:05):

alexcrichton commented on Issue #1376:

I'm actually a little confused myself as to this error, what's the sycall that's failing due to sharing?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 15:44):

peterhuene commented on Issue #1376:

Right now I'm doing a try_clone on the File we open/create for the file path specified in wasi_config_std[in|out|err]_path as well as wasi_config_preopen since it needs to be shared between the two underlying context builders. By default, it's not being opened with Windows sharing flags, so the try_clone is failing when trying to use those functions.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 15:49):

peterhuene commented on Issue #1376:

I have a solution in mind that's going to change the WASI C API functions so that users can request a particular WASI "module" and it'll be represented as a wasm_module_t and thus can be instantiated normally, rather than this special instance type. That should allow people to use the snapshot of WASI they want, provided the engine supports it.

The C# API would then change so that when you want to instantiate a module with WASI, you get an Instance like any other module and Module.Instantiate will take an enumeration of modules to link against, one of which can be an instantiated WASI module.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 15:50):

peterhuene edited a comment on Issue #1376:

I have a solution in mind that's going to change the WASI C API functions so that users can request a particular WASI "module" and it'll be represented as a wasm_module_t and thus can be instantiated normally, rather than this special wasi_instance_t type. That should allow people to use the snapshot of WASI they want, provided the engine supports it.

The C# API would then change so that when you want to instantiate a module with WASI, you get an Instance like any other module and Module.Instantiate will take an enumeration of modules to link against, one of which can be an instantiated WASI module.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 15:50):

peterhuene edited a comment on Issue #1376:

I have a solution in mind that's going to change the WASI C API functions so that users can request a particular WASI "module" and it'll be represented as a wasm_module_t and thus can be instantiated normally, rather than this special wasi_instance_t type. That should allow people to use the snapshot of WASI they want, provided the engine supports it.

The C# API would then change so that when you want to instantiate a module with WASI, you get an Instance like any other module and Module.Instantiate will take an enumeration of instances to link against, one of which can be an instantiated WASI module.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 15:53):

peterhuene edited a comment on Issue #1376:

I have a solution in mind that's going to change the WASI C API functions so that users can request a particular WASI "module" and it'll be represented as a wasm_module_t and thus can be instantiated normally, rather than this special wasi_instance_t type. That should allow people to use the snapshot of WASI they want, provided the engine supports it.

The C# API would then change so that when you want to instantiate a module with WASI, you get an Instance like any other module and Module.Instantiate will take an enumeration of instances to link against, one of which can be an instantiated WASI module.

This solution would forego this particular PR. I'm leaving this one open for now until I get that work finished.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 15:53):

peterhuene edited a comment on Issue #1376:

I have a solution in mind that's going to change the WASI C API functions so that users can request a particular WASI "module" and it'll be represented as a wasm_module_t and thus can be instantiated normally, rather than this special wasi_instance_t type. That should allow people to use the snapshot of WASI they want, provided the engine supports it.

The C# API would then change so that when you want to instantiate a module with WASI, you get an Instance like any other module and Module.Instantiate will take an enumeration of instances to link against, one of which can be an instantiated WASI module.

That solution would forego this particular PR. I'm leaving this one open for now until I get that work finished.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 16:29):

alexcrichton commented on Issue #1376:

Hm ok I think I'm not familiar enough with windows sharing things to know what's going on. I would naively think that we should open files with sharing rights and/or this is a bug in libstd if try_clone never works.

I'm slightly hesitant to get a wasm_module_t or a wasm_instance_t from wasi items since they're not actually compiled object code but rather more of a "everyone's gotta have a enum Instance with one variant as jit code and one as wasi modules. I also see though how it'd be quite nice to not have to deal with wasi instances at all and you've only got normal instances/modules. In that sense I think it definitely seems worthwhile to explore! I'll wait until I have some code to peek at :)

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 17:26):

peterhuene commented on Issue #1376:

We definitely can use the Windows stdlib extensions for opening with sharing to get this green, which is simple to do.

I'm just not a fan of this approach after (even) more consideration. This doesn't scale well as more and more snapshots get released and we have to support them, assuming we don't solve the problem with a single WASI instance that knows how to polyfill previous snapshots itself.

I'll take a stab at the alternative approach today and put it up for your review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 23 2020 at 17:28):

peterhuene edited a comment on Issue #1376:

We definitely can use the Windows stdlib extensions for opening with sharing to get this green, which is simple to do.

I'm just not a fan of this approach after (even) more consideration. This doesn't scale well as more and more snapshots get released and we have to support them, assuming we don't solve the problem with a single WASI instance that knows how to polyfill previous snapshots itself.

Regarding the enum problem, it should be at least limited to the C API to answer the "what kind of module is this?" question. At least it wouldn't complicate the Rust API unnecessarily.

I'll take a stab at the alternative approach today and put it up for your review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 26 2020 at 01:53):

peterhuene commented on Issue #1376:

I'm closing this in favor of the commit that adds support for WASI snapshot0 in #1411.

Last updated: Nov 22 2024 at 17:03 UTC