> Perhaps the best thing is just to fork(2), so we get a new (OS level) > process that has copy-on-write (virtual) memory, and if the compilation + > run succeeds in the child, then have the child "take over". Otherwise the > child dies with an fail! + location message, and we return to the parent > exactly before the child was spawned.
Do you intend for rusti to work on windows? Because I'm not sure you could do something like that efficiently there. On Fri, Sep 20, 2013 at 8:40 AM, Jason E. Aten <[email protected]> wrote: > On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton <[email protected]> wrote: >> >> Basically, I'm OK with leaving out tasks/spawned tasks from rusti, but >> I think that it should be important to be able to fail! and have the >> repl state intact afterwards. > > > Agreed. I'm convinced that fail! should result in an almost-magical "lets > pretend that never happened" jump back in time. > > I'm still trying to figure out how to do this efficiently. For code that has > alot of state, serializing and deserializing everything will be too slow. > > Perhaps the best thing is just to fork(2), so we get a new (OS level) > process that has copy-on-write (virtual) memory, and if the compilation + > run succeeds in the child, then have the child "take over". Otherwise the > child dies with an fail! + location message, and we return to the parent > exactly before the child was spawned. > > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
