Thanks for the speedy reply, Mark.
On Sunday, October 14, 2018 at 9:05:27 PM UTC-6, MarkM wrote:
>
> Hi Michael, the problem with any such mechanism is how to avoid corrupted
> state. The only consistent states for the heap, considered without the
> stack, are between turns when the stack is empty.
>
[...]
> To do the metering, we're planning to do a source-to-source rewrite
> inserting the equivalent of calls to your interceptor at least at function
> entries and loop body entries.
>
That's what I was planning.
Crucially, if the interceptor decides against continuing the computation,
> it does not throw an exception, as that would leave corrupted state.
> Instead it aborts the transaction, rolling back all effects that had
> happened so far during that turn.
>
I'm not understanding why throwing an exception at the beginning of a loop
body or function call in a Javascript implementation can create corrupted
state. Does that mean if I have client code that does:
for (var i = 0; i < 20; i ++) {
throw Error('I just corrupted your heap');
}
the host will die a horrible death?
Is this (and "transactions') part of the Caja internals?
Unfortunately, until both of those bits of engineering are done --- the
> source-to-source rewrite and the abortable turn bookkeeping --- I can't
> offer any practical advice.
>
I would have thought that the source-to-source transform would be fairly
easy, but don't understand the abortable bookkeeping.
Glad to see this is on your radar, though. I've been a follower since
erights.org went live, and it's great to see that the concepts are in use.
Thanks,
Michael.
--
---
You received this message because you are subscribed to the Google Groups
"Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
