Calling async code in sync trait
you can't turn async into sync in JS[1], but you can turn sync into async. I think what @kflansburg is poking around is that maybe you can think of a creative way to work around the type limitations of the trait in Rust, to turn it into some async thing you can use (or a sync thing you can poll).... but it's hard to see exactly what that would look like without seeing all the limitations you're facing. afaict this is not too far away from my channels solution above (which also turns sync+async into simple async in pure rust), and you're ultimately stuck from any of these ideas because you're somehow completely constrained by not having any async call-site where you can handle things.
[1] in other words, you can turn "something that happens now" into "something that happens in the future" by delaying it, but it's logically impossible to turn "something that happens in the future" into "something that happens now". The best you can do is "keep looping now, don't move forward, until that future event happens, just loop until we get to the future" - but you can't do that either because it's not really about time, it's about driving the process forward- and by looping you prevent that progress from being made (it's just stuck in the loop, nothing else can happen). The way around that is to put the thread to sleep so that progress can be made while you loop, but the workers environment disables the ability to do this for security reasons. So, all in all, there is no way at all to turn async into sync in the workers environment, as long as those security restrictions are in place.
3 Replies
Unknown User•8mo ago
Message Not Public
Sign In & Join Server To View
interesting, thanks for pointing that out!
it seems to me that asyncify is going the other direction, it's turning sync into async (i.e. "asyncifying" it) - BUT, but doing that, it can effectively turn the entire process async, so once you have that you can do nifty things like make it look sync from the perspective of C/emscripten...?
in other words, I don't think it's really sleeping and waiting for the promise resolve, it's more that the entire context becomes async, and so it can insert something more like hidden await points
feel free to correct me if I got that wrong though!
if the wasm code actually can busy-loop while allowing the promise to resolve, I'm very curious how (without a real thread sleep)
in other words, if I understood correctly, we're saying the same thing - but you're suggesting that this technique could also be done for Rust (i.e. it happens at a very low level, allowing to transform pretty much any wasm, in theory).
If that's right - I wouldn't know where to begin tinkering with that, but it would be pretty interesting/funny/scary/powerful to see something like an
await! macro that could be called anywhere.Unknown User•8mo ago
Message Not Public
Sign In & Join Server To View