On Sat, Jan 25, 2014 at 2:29 PM, Bill Myers <[email protected]> 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... Vadim
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
