Stream: git-wasmtime

Topic: wasmtime / PR #2304 wasi-common: add means to share handl...

Wasmtime GitHub notifications bot (Oct 21 2020 at 07:22):

ueno opened PR #2304 from wip/dueno/entries to main:

I am sure that this is not a good idea and there could be a better approach, but I would like to hear any opinions.

In our project, we want to open an I/O stream in a custom WASI module (or dynamically open it by the host) and somehow inject its handle to the main WASI module, to allow the guest to read/write with the fd_* functions. That is currently not possible because the FD management (EntryTable) is internal to the wasi-common crate.

I'm wondering if EntryTable can be made public, with a couple of registration/lookup methods, so other modules can register FD through it. A typical usage would be:

  // Create a centrally managed file descriptor table.
  let entries = EntryTable::new();

  // Create WasiCtx with the table.
  let mut builder = WasiCtxBuilder::new();
  let ctx = builder.entries(entries).build();

  // Create a context of an external WASI module with the same table.
  let mut builder = WasiOtherCtxBuilder::new();
  let ctx = builder.entries(entries).build();

The implementation of WasiOtherCtx can create a Handle internally and register it with EntryTable::insert_handle.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [x] This has been discussed in issue #..., or if not, please tell us why
  here.

• [x] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 21 2020 at 13:55):

ueno updated PR #2304 from wip/dueno/entries to main:

I am sure that this is not a good idea and there could be a better approach, but I would like to hear any opinions.

In our project, we want to open an I/O stream in a custom WASI module (or dynamically open it by the host) and somehow inject its handle to the main WASI module, to allow the guest to read/write with the fd_* functions. That is currently not possible because the FD management (EntryTable) is internal to the wasi-common crate.

I'm wondering if EntryTable can be made public, with a couple of registration/lookup methods, so other modules can register FD through it. A typical usage would be:

  // Create a centrally managed file descriptor table.
  let entries = EntryTable::new();

  // Create WasiCtx with the table.
  let mut builder = WasiCtxBuilder::new();
  let ctx = builder.entries(entries).build();

  // Create a context of an external WASI module with the same table.
  let mut builder = WasiOtherCtxBuilder::new();
  let ctx = builder.entries(entries).build();

The implementation of WasiOtherCtx can create a Handle internally and register it with EntryTable::insert_handle.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [x] This has been discussed in issue #..., or if not, please tell us why
  here.

• [x] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 21 2020 at 19:18):

ueno updated PR #2304 from wip/dueno/entries to main:

I am sure that this is not a good idea and there could be a better approach, but I would like to hear any opinions.

In our project, we want to open an I/O stream in a custom WASI module (or dynamically open it by the host) and somehow inject its handle to the main WASI module, to allow the guest to read/write with the fd_* functions. That is currently not possible because the FD management (EntryTable) is internal to the wasi-common crate.

I'm wondering if EntryTable can be made public, with a couple of registration/lookup methods, so other modules can register FD through it. A typical usage would be:

  // Create a centrally managed file descriptor table.
  let entries = EntryTable::new();

  // Create WasiCtx with the table.
  let mut builder = WasiCtxBuilder::new();
  let ctx = builder.entries(entries).build();

  // Create a context of an external WASI module with the same table.
  let mut builder = WasiOtherCtxBuilder::new();
  let ctx = builder.entries(entries).build();

The implementation of WasiOtherCtx can create a Handle internally and register it with EntryTable::insert_handle.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [x] This has been discussed in issue #..., or if not, please tell us why
  here.

• [x] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 22 2020 at 05:03):

ueno updated PR #2304 from wip/dueno/entries to main:

I am sure that this is not a good idea and there could be a better approach, but I would like to hear any opinions.

In our project, we want to open an I/O stream in a custom WASI module (or dynamically open it by the host) and somehow inject its handle to the main WASI module, to allow the guest to read/write with the fd_* functions. That is currently not possible because the FD management (EntryTable) is internal to the wasi-common crate.

I'm wondering if EntryTable can be made public, with a couple of registration/lookup methods, so other modules can register FD through it. A typical usage would be:

  // Create a centrally managed file descriptor table.
  let entries = EntryTable::new();

  // Create WasiCtx with the table.
  let mut builder = WasiCtxBuilder::new();
  let ctx = builder.entries(entries).build();

  // Create a context of an external WASI module with the same table.
  let mut builder = WasiOtherCtxBuilder::new();
  let ctx = builder.entries(entries).build();

The implementation of WasiOtherCtx can create a Handle internally and register it with EntryTable::insert_handle.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [x] This has been discussed in issue #..., or if not, please tell us why
  here.

• [x] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 22 2020 at 14:06):

ueno updated PR #2304 from wip/dueno/entries to main:

I am sure that this is not a good idea and there could be a better approach, but I would like to hear any opinions.

In our project, we want to open an I/O stream in a custom WASI module (or dynamically open it by the host) and somehow inject its handle to the main WASI module, to allow the guest to read/write with the fd_* functions. That is currently not possible because the FD management (EntryTable) is internal to the wasi-common crate.

I'm wondering if EntryTable can be made public, with a couple of registration/lookup methods, so other modules can register FD through it. A typical usage would be:

  // Create a centrally managed file descriptor table.
  let entries = EntryTable::new();

  // Create WasiCtx with the table.
  let mut builder = WasiCtxBuilder::new();
  let ctx = builder.entries(entries).build();

  // Create a context of an external WASI module with the same table.
  let mut builder = WasiOtherCtxBuilder::new();
  let ctx = builder.entries(entries).build();

The implementation of WasiOtherCtx can create a Handle internally and register it with EntryTable::insert_handle.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [x] This has been discussed in issue #..., or if not, please tell us why
  here.

• [x] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 24 2020 at 19:28):

pchickey submitted PR Review.

Wasmtime GitHub notifications bot (Nov 24 2020 at 19:28):

pchickey created PR Review Comment:

Should this be &self instead of &mut self?

Wasmtime GitHub notifications bot (Nov 25 2020 at 05:10):

ueno updated PR #2304 from wip/dueno/entries to main:

I am sure that this is not a good idea and there could be a better approach, but I would like to hear any opinions.

In our project, we want to open an I/O stream in a custom WASI module (or dynamically open it by the host) and somehow inject its handle to the main WASI module, to allow the guest to read/write with the fd_* functions. That is currently not possible because the FD management (EntryTable) is internal to the wasi-common crate.

I'm wondering if EntryTable can be made public, with a couple of registration/lookup methods, so other modules can register FD through it. A typical usage would be:

  // Create a centrally managed file descriptor table.
  let entries = EntryTable::new();

  // Create WasiCtx with the table.
  let mut builder = WasiCtxBuilder::new();
  let ctx = builder.entries(entries).build();

  // Create a context of an external WASI module with the same table.
  let mut builder = WasiOtherCtxBuilder::new();
  let ctx = builder.entries(entries).build();

The implementation of WasiOtherCtx can create a Handle internally and register it with EntryTable::insert_handle.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [x] This has been discussed in issue #..., or if not, please tell us why
  here.

• [x] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 25 2020 at 05:10):

ueno submitted PR Review.

Wasmtime GitHub notifications bot (Nov 25 2020 at 05:10):

ueno created PR Review Comment:

Fixed; thanks!

Wasmtime GitHub notifications bot (Mar 13 2024 at 02:20):

alexcrichton closed without merge PR #2304.

Wasmtime GitHub notifications bot (Mar 13 2024 at 02:20):

alexcrichton commented on PR #2304:

This is a pretty old PR at this point and lots has changed in the interim, especially around WASI, so I'm going to close this. If there's still bits to pull in today though I think it'd be good to update and re-send.

Last updated: Dec 23 2024 at 12:05 UTC