Hi Raphael, that does seem like a small drawback. But I don't see a better solution. Still open to suggestions.
On Fri, Sep 20, 2013 at 12:07 AM, raphael catolino < raphael.catol...@gmail.com> wrote: > > 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 <j.e.a...@gmail.com> wrote: > > On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton <a...@crichton.co> > 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 > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
