On May 14, 2009, at 5:42 PM, Mark S. Miller wrote:
On Thu, May 14, 2009 at 3:42 PM, Brendan Eich <[email protected]>
wrote:
On May 14, 2009, at 2:50 PM, Mark S. Miller wrote:
If so, did you have a different way of reasoning about the
reasons today
why
finally might not run that I mentioned (iloop detection or other
hard
stop)?
Those hard stops kill all further activity within that event loop.
Once a universe has been destroyed, no further bad things can happen
in that universe.
There's always the next universe (new event starts another control
flow).
Life goes on, in the JS serial multiverse, and those finally
clauses failed
to run even though control abruptly left the lambda under the
hypothesis.
I am assuming that a hard stop destroying an event loop also destroys
(at least makes inaccessible) all objects that were able to execute
within that event loop.
You're right that this is necessary with threads and fail-stop
information flow systems, but plain old iloop DOS prevention as
practiced in browsers does *not* reload the page. And the browser APIs
are full of ways to detect that finallys didn't run, through effects
overt and covert.
This isn't entirely academic, since information leaks include
termination
channels.
I do not expect to be able to plug such information leakage channels,
and was not trying to. But again, this doesn't endanger any object
invariants.
Just consider iloop DOS prevention as practiced in browsers today:
finally may not run. That's enough.
A similar, but (to me at least) more surprising information leakage
channel is something I've called "The Anthropic Side Channel":
[fun example snipped]
So, the anthropic side channel enables B to communicate what Brendan
might call a half a bit of information to C.
You must be referring to my slides at http://www.dagstuhl.de/Materials/index.en.phtml?09141
-- I should have better slides blogged next week.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
