pchickey commented on issue #7260:
More feedback, based on discussion with @elliottt:
- Do we need to express an output-stream that can potentially have an unbounded number of input-streams forwarded to it? It would perhaps be much simpler if
forward
consumed both theinput-stream
andoutput-stream
, andfuture-forward-result
gave back theoutput-stream
as well as theu64
in thesome(ok(ok(...))
case.- I am concerned this could be too powerful, and force us to make some difficult implementation choices, when applied to all streams. We have the use case of forwarding http bodies. Could we instead implement this as a static method on
outgoing-body
as an alternative tofinish
which is something likefinish-by-forwarding: static func(this: outgoing-body, forward: input-stream) -> some-future
. That still requires us to keep thatinput-stream
alive beyond the lifetime of the wasm execution, which could be the same can of worms...
pchickey edited a comment on issue #7260:
More feedback, based on discussion with @elliottt:
- Do we need to express an output-stream that can potentially have an unbounded number of input-streams forwarded to it? It would perhaps be much simpler if
forward
consumed both theinput-stream
andoutput-stream
, andfuture-forward-result
gave back theoutput-stream
as well as theu64
in thesome(ok(ok(...))
case.- I am concerned this could be too powerful, and force us to make some difficult implementation choices, when applied to all streams. We have the use case of forwarding http bodies. Could we instead implement this as a static method on
outgoing-body
as an alternative tofinish
which is something likefinish-by-forwarding: static func(this: outgoing-body, forward: input-stream) -> some-future
. That still requires us to keep thatinput-stream
alive beyond the lifetime of the wasm execution, which could be the same can of worms... for example, what happens when that input-stream is derived from a socket, or a file. now we need to be able to keep those open beyond the lifetime of wasm execution... we'd basically have to keep the entire Table alive (or have some sort of fancy garbage collection) until all forwarding is over, so all we'd be able to free during forward is the linear memory.
pchickey edited a comment on issue #7260:
More feedback, based on discussion with @elliottt:
- Do we need to express an output-stream that can potentially have an unbounded number of input-streams forwarded to it? It would perhaps be much simpler if
forward
consumed both theinput-stream
andoutput-stream
, andfuture-forward-result
gave back theoutput-stream
as well as theu64
in thesome(ok(ok(...))
case.- I am concerned this could be too powerful, and force us to make some difficult implementation choices, when applied to all streams. We have the use case of forwarding http bodies. Could we instead implement this as a static method on
outgoing-body
as an alternative tofinish
which is something likefinish-by-forwarding: static func(this: outgoing-body, forward: input-stream) -> some-future
. That still requires us to keep thatinput-stream
alive beyond the lifetime of the wasm execution, which could be the same can of worms... for example, what happens when that input-stream is derived from a socket, or a file. now we need to be able to keep those open beyond the lifetime of wasm execution... we'd basically have to keep the entire Table alive (or have some sort of fancy garbage collection) until all forwarding is over, so all we'd be able to free during forward is the linear memory.This was the can of worms I was trying to avoid opening, and I'm worried about painting ourselves into a corner by requiring certain behavior happen in the background and beyond the lifetime of the component.
pchickey edited a comment on issue #7260:
More feedback, based on discussion with @elliottt:
- Do we need to express an output-stream that can potentially have an unbounded number of input-streams forwarded to it? It would perhaps be much simpler if
forward
consumed both theinput-stream
andoutput-stream
, andfuture-forward-result
gave back theoutput-stream
as well as theu64
in thesome(ok(ok(...))
case.- I am concerned this could be too powerful, and force us to make some difficult implementation choices, when applied to all streams. We have the use case of forwarding http bodies. Could we instead implement this as a static method on
outgoing-body
as an alternative tofinish
which is something likefinish-by-forwarding: static func(this: outgoing-body, forward: input-stream) -> some-future
. That still requires us to keep thatinput-stream
alive beyond the lifetime of the wasm execution, which could be the same can of worms... for example, what happens when that input-stream is derived from a socket, or a file. now we need to be able to keep those open beyond the lifetime of wasm execution... we'd basically have to keep the entire Table alive (or have some sort of fancy garbage collection) until all forwarding is over, so all we'd be able to free during forward is the linear memory.This was the can of worms I was trying to avoid opening, and I'm worried about painting ourselves into a corner by requiring certain behavior happen in the background and beyond the lifetime of the component. Could we scope this down to an interaction that only happens as long as the
future-forwarded-result
is alive, and not try to return from execution until forwarding has complete, just waiting in a poll_list until the forwarding is complete? That will save on lots of back and forth interaction between host and guest, at least.
alexcrichton commented on issue #7260:
I believe the current conclusion is to defer this to after the 0.2.0 release of WASI, so I'm going to close this as it's probably best to pick back up discussion after that happens, but please reopen if you disagree
Last updated: Dec 23 2024 at 12:05 UTC