Joel Dice

Alternatively, it could be `impl Future`, but then we'd want to make sure `wit-bindgen-rt` has some form of interop between `ErrorContext` and `anyhow::Error` and make sure the `?` operator "just...

> I'm less certain on what would be possible to do with an error in this case. You say we can close open futures/streams but how would that be enumerated?...

Wild idea: we could store the `ErrorContext` in a thread-local variable prior to dropping the spawned `Future` after it has returned `Poll::Ready(Err(_))`, and any handles which are closed while that...

I.e. we wouldn't be dropping all the streams and futures which "belong to the task" -- just the ones that literally (in the Rust ownership sense) belong to that specific...

> Personally I want to more-or-less get rid of `HANDLES` or otherwise only rely on it in very few circumstances. Fair enough; my thread-local `ErrorContext` idea wouldn't require it anyway....

Thanks, @lukewagner -- makes sense. The more I've thought about it, the more I think it's not really a matter of which streams/futures belong to a given component-level task anyway...

I just realized this PR doesn't include support for accepting incoming connections -- only initiating outgoing ones. I forgot about the former since I don't personally have an urgent need...

> Also, I have a last clarifying question: reading wasi-libc I assumed that all Pollable are abstracted as a Socket but this socket is a "fake" one in the sense...

BTW, this PR doesn't include UDP support either, again because that hasn't been a priority for me. Shouldn't be hard to add as a follow-up PR.

> My question was more related to how `pollable` obtained from types not related to `sockets` are usable in `mio` context, for example, the streams you mentioned can also be...