On 06/02/2013 03:44 PM, Brian Anderson wrote:
On 06/01/2013 11:49 PM, Matthieu Monrocq wrote:
On Sat, Jun 1, 2013 at 8:35 PM, Vadim <vadi...@gmail.com
<mailto:vadi...@gmail.com>> wrote:
On Sat, Jun 1, 2013 at 7:47 AM, Matthieu Monrocq
<matthieu.monr...@gmail.com <mailto:matthieu.monr...@gmail.com>>
wrote:
1. Futures use a custom free-list allocator for
performance.
I don't see why Futures could not be allocated on the stack ?
Since Rust is move aware and has value types, it seems to me
this should be possible.
Because I/O manager needs to know where that future is in order
to fill in the result.
Perhaps it's possible to have a stack-allocated future objects
that consist of just a raw pointer to a block owned by the I/O
manager. But these would need to have by-move semantics in order
to emulate behavior of unique pointers. I am not entirely sure
how by-move vs by-copy is decided, but according to this
<http://static.rust-lang.org/doc/rust.html#moved-and-copied-types> Rust
would choose by-copy.
Vadim
Actually, I was more thinking of reserving space on the stack for the
return value and have to IO layer write directly into that space
(akin to C++'s Return Value Optimization).
However I might be stumbling on ABI issues here, since it essentially
means that the compiler transforms "Args... -> ~Future" into
"Args..., &mut Future -> ()".
In some scenarios it could be an important optimization to let async
results be written directly into the stack, but this requires further
safety guarantees that the receiver can't move from the stack, as you
say. That strikes me more as a fork/join style computation - which may
be an appropriate solution here - but I wouldn't want to couple
general-purpose futures to stack-discipline.
One other note. I expect Future return values to still be written `->
Future`. The allocation they require is an internal implementation
detail - they don't need an extra ~.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
