Skip to content

issues Search Results · repo:bytecodealliance/wasip3-prototyping language:Rust

Filter by

17 results
 (58 ms)

17 results

inbytecodealliance/wasip3-prototyping (press backspace or delete to remove)

Not sure if this is a in issue in wit-bindgen, wasmtime or both, but it appears that the Waker functionality does not function correctly in Rust guests when using async exports. For example: use futures::channel::mpsc; ...
  • rvolosatovs
  • Opened 
    3 days ago
  • #66

This test (component definition $a (component $C (core module $m (global $g (mut i32) (i32.const 0)) (func (export take ) (param i32) local.get 0 global.set $g) (func (export ...
  • alexcrichton
  • Opened 
    6 days ago
  • #53

There s currently no way to close the host stream reader handle with an error, e.g. when the host is streaming data into some fallible I/O sink, e.g. https://github.com/bytecodealliance/wasip3-prototyping/blob/de530d78737430989b416bdf824ba860c397398c/crates/wasi/src/p3/cli/host.rs#L84 ...
  • rvolosatovs
  • 2
  • Opened 
    6 days ago
  • #51

Found via https://github.com/bytecodealliance/wasip3-prototyping/pull/43, replicated locally with: $ cargo test -p component-async-tests --target i686-unknown-linux-gnu Note that this requires disabling ...
  • alexcrichton
  • 1
  • Opened 
    10 days ago
  • #45

I ve seen this twice now on CI; rerunning the job usually fixes it (but apparently erases the log of the failure, alas). Here s the error: failures: ---- p3::sockets::sockets_0_3_udp_sample_application ...
  • dicej
  • 4
  • Opened 
    10 days ago
  • #44

Currently, calling a host export implemented as async using concurrent_import as a sync import from an async export in the guest causes a deadlock. See #40 for a test case with a repro. Note, that the ...
  • rvolosatovs
  • 1
  • Opened 
    10 days ago
  • #41

Pointed out in https://github.com/bytecodealliance/wasmtime/issues/10262 the host futures are currently bound by both Send and Sync, but only Send should be required there.
  • alexcrichton
  • 2
  • Opened 
    13 days ago
  • #30

i.e. the close syscall should absolutely be called, without blocking indefinitely for close.
  • vados-cosmonic
  • 5
  • Opened 
    13 days ago
  • #29

i.e. the close syscall should absolutely be called, without blocking indefinitely for close.
  • t3hmrman
  • Opened 
    13 days ago
  • #27
Issue origami icon

Learn how you can use GitHub Issues to plan and track your work.

Save views for sprints, backlogs, teams, or releases. Rank, sort, and filter issues to suit the occasion. The possibilities are endless.Learn more about GitHub Issues
ProTip! 
Press the
/
key to activate the search input again and adjust your query.
Issue origami icon

Learn how you can use GitHub Issues to plan and track your work.

Save views for sprints, backlogs, teams, or releases. Rank, sort, and filter issues to suit the occasion. The possibilities are endless.Learn more about GitHub Issues
ProTip! 
Press the
/
key to activate the search input again and adjust your query.
Issue search results · GitHub