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

Vadim vadimcn at gmail.com
Sat Jan 25 16:50:44 PST 2014

On Sat, Jan 25, 2014 at 2:29 PM, Bill Myers <bill_myers at outlook.com> wrote:

> Interesting: my proposal appears to be indeed a generalization of the
> greenlet approach.
> Specifically, while the greenlet proposal seems to only use one large
> stack per native thread, I'm suggesting to use multiple large stacks that
> can be stolen by other threads, which does mitigate the issues stemming
> from non-position dependent stacks (they are not eliminated, but they have
> low probability of happening).

You'd still have to be very careful to not perform any significant amount
of computation in a greenlet, as to not block all other greenlets it shares
the OS stack with.
Although... I don't see any reason we could not use non-cooperative
greenlet switching as a backstop (i.e. have some watchdog thread suspend
the offending greenlet, and forcibly swap it out).

It's also indeed possible to fully eliminate those issues by autoboxing
> everything whose address is taken, but that would have a potentially large
> performance impact on non-blocking code, while merely copying the stack
> only imposes a performance penalty to code that blocks.

True.   It might be possible to restrict this transform only to functions
that might be on the stack when a greenlet is swapped out, though.
Unfortunately, this will probably require some kind of pluggable effects
system in the language,- e.g. mark I/O functions like read() and write() as
potentially yielding with a special trait, then the compiler could
propagate this trait to all callers, and so on...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140125/650bc159/attachment.html>

More information about the Rust-dev mailing list