Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WASI in the C API #840

Closed
liamappelbe opened this issue Sep 26, 2019 · 8 comments
Closed

WASI in the C API #840

liamappelbe opened this issue Sep 26, 2019 · 8 comments
Assignees
@MarkMcCaskey
Labels
❓ question I've a question!

Comments

@liamappelbe
Copy link

Wasmer seems to support WASI, but I'm not sure how to use WASI through wasmer.hh
@liamappelbe liamappelbe added the ❓ question I've a question! label Sep 26, 2019
@syrusakbary
Copy link
Member

We haven't exposed WASI through the c-api yet, but we will soon! 🙂

Are there any time constraints on when you will need that? (to make sure we fulfill them!)

@liamappelbe
Copy link
Author

Not super urgent. Some time in the next couple of months would be great. How much work do you think it will be?

@MarkMcCaskey
Copy link
Contributor

MarkMcCaskey commented Sep 26, 2019 •
edited
Loading

It depends on which features we need to support; our Rust WASI API supports creating virtual files with arbitrary backing logic that can be swapped with files at runtime (and these virtual files can be safely serialized and deserialized allowing for snapshots of the filesystem) -- that's something that will require some solid design work to make portable and nice to use across languages. We haven't started that design work yet because this Rust WASI FS API is relatively new and we're waiting for more feedback before porting it.

But for general execution of WASI, there's only one blocker on the WASI side that I'm aware of. It has to do with the WASI state owning filesystem resources directly which means that our state creation function can't safely be run twice because they'll fight over filesystem resources. This is somewhat of an edge case though and something that's near the top of my todo list to fix.

It's my understanding that we could probably get this "working" on the C-side pretty quickly -- I don't have full context on exactly what we expose, so it may require extra work to make it nice/properly usable which is why I put "working" in scare quotes.

@liamappelbe
Copy link
Author

Thanks for the quick responses. Off the top of my head I can't think of any advanced features we'll need, but I'll confirm with my team.

bookmoons pushed a commit to bookmoons/wasmer that referenced this issue Oct 1, 2019
@bors @dependabot-preview
Merge wasmerio#808
0ea5b1b 
808: Bump rand from 0.7.0 to 0.7.2 r=MarkMcCaskey a=dependabot-preview[bot]

Bumps [rand](https://github.com/rust-random/rand) from 0.7.0 to 0.7.2.
<details>
<summary>Changelog</summary>

*Sourced from [rand's changelog](https://github.com/rust-random/rand/blob/master/CHANGELOG.md).*

> ## [0.7.2] - 2019-09-16
> ### Fixes
> - Fix dependency on `rand_core` 0.5.1 ([wasmerio#890](https://github-redirect.dependabot.com/rust-random/rand/issues/890))
> 
> ### Additions
> - Unit tests for value stability of distributions added ([wasmerio#888](https://github-redirect.dependabot.com/rust-random/rand/issues/888))
> 
> ## [0.7.1] - 2019-09-13
> ### Fixes
> - Fix `no_std` behaviour, appropriately enable c2-chacha's `std` feature ([wasmerio#844](https://github-redirect.dependabot.com/rust-random/rand/issues/844))
> - `alloc` feature in `no_std` is available since Rust 1.36 ([wasmerio#856](https://github-redirect.dependabot.com/rust-random/rand/issues/856))
> - Fix or squelch issues from Clippy lints ([wasmerio#840](https://github-redirect.dependabot.com/rust-random/rand/issues/840))
> 
> ### Additions
> - Add a `no_std` target to CI to continously evaluate `no_std` status ([wasmerio#844](https://github-redirect.dependabot.com/rust-random/rand/issues/844))
> - `WeightedIndex`: allow adjusting a sub-set of weights ([wasmerio#866](https://github-redirect.dependabot.com/rust-random/rand/issues/866))
</details>
<details>
<summary>Commits</summary>

- [`249ebfc`](rust-random/rand@249ebfc) Merge pull request [wasmerio#888](https://github-redirect.dependabot.com/rust-random/rand/issues/888) from dhardy/master
- [`5ac4cbd`](rust-random/rand@5ac4cbd) Prepare rand 0.7.2
- [`f39915a`](rust-random/rand@f39915a) rand_distr: work around tan func issue
- [`802ba8f`](rust-random/rand@802ba8f) rand_distr: add missing value_stability tests
- [`a43d7f1`](rust-random/rand@a43d7f1) Fix tests
- [`2ef2e66`](rust-random/rand@2ef2e66) Add value_stability tests for uniform
- [`096a5dd`](rust-random/rand@096a5dd) UniformSampler: add doc on usage of sample_single
- [`f78781a`](rust-random/rand@f78781a) Uniform: replace inner field with struct tuple
- [`856fdfb`](rust-random/rand@856fdfb) Distribution: add doc of portability
- [`72af6f8`](rust-random/rand@72af6f8) Add value_stability tests for bernoulli, int, float and other distrs
- Additional commits viewable in [compare view](rust-random/rand@0.7.0...0.7.2)
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=rand&package-manager=cargo&previous-version=0.7.0&new-version=0.7.2)](https://dependabot.com/compatibility-score.html?dependency-name=rand&package-manager=cargo&previous-version=0.7.0&new-version=0.7.2)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Pull request limits (per update run and/or open at any time)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
@liamappelbe
Copy link
Author

I've talked to my team, and we don't need any advanced features. We will need to import our own functions in addition to WASI, but other than that the default behavior should be fine.

@MarkMcCaskey
Copy link
Contributor

Sorry about the delay! A lot of things kept coming up, but it just merged into master #856 .

Let us know if you run into any issues with it and we'll quickly fix them for you!

@liamappelbe
Copy link
Author

The API looks good. I'll give it a try once it's released. Thanks.

@MarkMcCaskey MarkMcCaskey self-assigned this Nov 1, 2019
@MarkMcCaskey
Copy link
Contributor

This is shipping in 0.10.0 which is in the process of being released now. Feel free to reopen or create a new issue if there are any problems!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@MarkMcCaskey MarkMcCaskey

Labels
❓ question I've a question!
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@syrusakbary @MarkMcCaskey @liamappelbe