It this not possible to do with tasks? If you could architect the dance between tasks of "who is the current master", then it seems like you wouldn't need to have forking at all. The "fail and forget" is automatic because failure is caught at task boundaries anyway. Not entirely sure if this would work, though.
On Fri, Sep 20, 2013 at 7:26 AM, Jason E. Aten <[email protected]> wrote: > 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 > <[email protected]> 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 <[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
