Threadsafe futures

[ibaryshnikov]

Closes #1379

Changes:

• Added extern function wait_async, which does the same as Atomics::waitAsync
• Removed impl Notify for Package, also removed Send + Sync markers for Package
• Added Waker struct instead, which implements Notify
• Used Waker instead of Package to notify the executor

[alexcrichton]

I think the general structure that this is going to want to take is that spawning a future creates two main allocations. One is a Rc (or something like that) which holds the future itself. Another is an Arc which has some shared state. When creating a waker the Arc is what's shared, and its notify implementation will probably look like:

if !self.notified.swap(true) {
    // run an atomic notify at the address of `&self.notified`
}

In the poll loop I think it would look roughly like:

let promise = wait_async_on(&self.notified);
while self.notified.swap(true) {
    // do the poll
}
promise.then(&poll_again);

[ibaryshnikov]

Does it mean that the state with Polling | Notified | Waiting will be removed, and there will be only true or false?

[alexcrichton]

Oh what I gisted was just a straw man, it may be that two bits are still needed rather than one for information exchange.

[ibaryshnikov]

@alexcrichton the pr is not tested yet, I pushed changes to check the design.
There are several places to check: first, I removed impl Notify for Package. Then, instead of &me, there is &me.waker passed to poll_future_notify.
And I moved code from impl Notify for Package to fn poll_again
Inside fn poll_again Promise::resolve was replaced with wait_async
Did I get your idea right?

[alexcrichton]

This looks along the right lines yeah! There's probably a lot of devils in the details, but I think the general direction here is where we want to go.

[ibaryshnikov]

@alexcrichton I think I hit the wall here: #1525
There's a need to either make js snippets work with node target or replace the snippet with polyfill with the wasm equivalent. What do you think is better?

[alexcrichton]

Yeah it may be some time before snippets work on Node, so it's probably best to not block this on that. Perhaps the polyfill could be implemented in Rust though?

[alexcrichton]

Some great progress!

[ibaryshnikov]

@alexcrichton thank you for a great review! I fixed most of the places, but still have some questions, like usage of AtomicI32, or simplifying Waker struct. Btw, it looks working, and after increasing default timeout from 0 to 10ms the performance looks fine. So it's probably a time to start making changes to raytrace_parallel example itself?

[alexcrichton]

This is some comments on the polyfill at least, I'll try to get to the futures implementation later this week!

[ibaryshnikov]

@alexcrichton I fixed most of the places, but still have some where I'm not sure, like what to do with closures, and the contents of the Waker struct, which is currently

struct Waker {
    value: AtomicI32,
    notified: AtomicBool,
}

[alexcrichton]

Sorry for the delays, travel got the best of me! But yes the notified field can be removed and just value needs to be there, and we can use flags in value to indicate whether polling needs to happen and such.

[ibaryshnikov]

Updated to the latest master (I hope I didn't miss anything). Removed notified field, there's only value now inside Waker.
Can we summarize, what's left to do in this pr? I'm kind of lost in the comments.

[alexcrichton]

Ok thanks for the update @ibaryshnikov!

I've added a few more commits which cleaned up a few things (good chunks of the old future_to_promise implementation aren't necessary when using waitAsync) and reorganized some files a bit. I also hooked up the parallel raytrace example and can confirm it's all plumbed together and at least rudimentarily working.

If CI is green and you're good with this I think it's good to merge!

[ibaryshnikov]

@alexcrichton I'm good with this. Thanks for moving this forvard! And thanks for your comments, I've learned a lot from this pr!)

[alexcrichton]

Ok let's merge then, thanks so much again @ibaryshnikov!

[maxammann]

I think I found a usecase which is incomatible with this PR: #3048