Avoid thread creation when chaining continuations

[jnicholls]

It makes sense to have the promise chain begin in a new thread from Promise::new(), however beyond that the continuations themselves shouldn't be in separate threads of their own. They should all run on the originating thread where the Promise was created.

Apart from the thread locality of the continuations, the idea of creating a separate thread for each continuation is expensive. These aren't green threads, and so I'm afraid this Promise implementation will not scale well when put to the test.

[bcndanos]

I tried to find a better solution but I didn't find it.
The main problem is that this doesn't work in rush:

let mut v = vec![];
let function_a = || { println!("Hello"); };
let function_b = || { println!("Hello"); };
v.push(function_a);
v.push(function_b);

I can't accumulate clousures into a collection due to "no two closures, even if identical, have the same type". The only way that I found is to leave a new thread waiting through a mpsc channel. It doesn't consume CPU but only memory.

Obviously if you try to run 20,000 threads at the same time, your program will crash. That's why there's a Struct called 'EventLoop' in the same crate, that runs in only one thread and can handle multiple "Events".

[jnicholls]

I can't accumulate clousures into a collection due to "no two closures, even if identical, have the same type".

Not true. They just need to be boxed up. http://is.gd/4HxeRj

Obviously if you try to run 20,000 threads at the same time, your program will crash.

The issue isn't the inability to have a bunch of promises running at the same time, but the start up, tear down, and context switching costs involved for even a single chain of continuations.

I wrote a Promise implementation in C++, and no threading was involved whatsoever. Given that you can maintain a list of success and failure callbacks as shown above, this would be the optimal implementation. Leave it up to the user of the library to do the threading (or not).

[bcndanos]

The Box works only for one type of return, but you can't chain diferrent results. http://is.gd/I2nMCF

And there's another problem. As you can see on the code the 'Promise::new()' spawns the thread inmediatly, and later you can't run anything else in the same thread.

As you say, I'm going to think another way to do it in only one thread, but I'll keep the current implementation to let the user choose.

[bcndanos]

I've created a new branch named 'unstable' that uses a struct Deferred that doesn't use threads. It works fine, though the problem now is the project uses the unstable trait FnBox: https://doc.rust-lang.org/std/boxed/trait.FnBox.html

I wait until the rust team deliver a stable solution for that.

[jnicholls]

Ok awesome. There is a way to use Fn() instead by sticking captured variables into a RefCell<Option<T>> first, moving that in, and mutably borrowing the value and take() out the Option's value. You can also just use an Option<> w/ FnMut if you don't care about capturing everything as mutable.

But, I imagine FnBox will be stable w/ the 1.1 release in the next 5 weeks or so.

[bcndanos]

I've tried your work around but I have to use a Fn() instead of a FnOnce() and my code doesn't compile. It's too difficult for me.
If you wish send me a 'Pull Request' with the changes. If not, I'll wait until the stable solution of the rust team.