On 09/19/2013 11:40 PM, Jason E. Aten wrote:
On Thu, Sep 19, 2013 at 11:51 AM, Alex Crichton <[email protected]
<mailto:[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.
It seems a shame to be relying on process isolation instead of tasks. If
I were to just imagine the architecture of a repl that used task
isolation for crash recovery it might have one task for accepting input
and another as a sandbox that maintains the repl state and executes
commands in a loop.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
