[rust-dev] Idea: Memcpyed stacks for green tasks

Gábor Lehel glaebhoerl at gmail.com
Sun Jan 26 05:07:22 PST 2014

On Sun, Jan 26, 2014 at 2:02 PM, Gábor Lehel <glaebhoerl at gmail.com> wrote:

> On Sat, Jan 25, 2014 at 9:26 PM, Vadim <vadimcn at gmail.com> wrote:
>> Hi Bill,
>> If I understand this right, what you are proposing is the approach of
>> Python's greenlets library, which I already tried to pitch here<http://mail.mozilla.org/pipermail/rust-dev/2013-November/006544.html>.
>> I think that the biggest problem with this approach, in its' raw form, is
>> that greenlets are bound to a specific OS thread, which would cause all
>> sorts of headache.  For example:
>> - It would be difficult to balance greenlet tasks between several OS
>> threads,
>> - If async I/O requests for two greenlets, bound to the same OS thread,
>> were to complete simultaneously, you would not be able to resume them in
>> parallel,
>> - If a thread were to become blocked for a significant amount of time,
>> all the greenlets bound to it become un-resumable,
>> and so on...
>> Greelets would be much more palatable if their stacks were
>> position-independent.  This might be possible to achieve with a suitable
>> LLVM transform<http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069662.html>,
>> though I am not yet sure how portable this would be.
> Totally not an expert in this area, but I'm wondering two things:
>  - Once you hoist all variables whose address is taken out into this
> secondary stack frame, if you have a pointer on the stack to an object on
> the stack who *also*, in turn, has its address taken, then I believe you
> would end up with a pointer in the secondary stack frame to an object in
> the secondary stack frame, i.e. the secondary stack frame itself would not
> be position independent. Does the secondary stack frame always stay in
> place, so we don't really care about this?

(Thinking about this further, this was a silly question, because the
primary stack frame itself would have pointers into the secondary one, so
_obviously_ the latter cannot move.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140126/d2ee76c9/attachment-0001.html>

More information about the Rust-dev mailing list