19:00
<bakkot>
fun use case for ShadowRealms: running code generated by an LLM https://simonwillison.net/2024/Oct/24/claude-analysis-tool/
19:00
<bakkot>
this didn't actually use ShadowRealms, presumably because they don't exist yet
19:00
<bakkot>

but same use case:

it executes that JavaScript directly in your browser—in a locked down Web Worker that communicates back to the main page by intercepting messages sent to console.log()

19:01
<bakkot>
though I guess you'd really also need the ability to kill long-running code, which means you'd need to use a realm in a worker, or something like that
19:07
<shu>
yeah the early termination use case is surprisingly common i think
19:07
<shu>
shadowrealms make that impossible because of the sync-ness
19:10
<bakkot>
wonder if we could have something in the language for that... like, it is already the case that you might OOM at any point, so it probably isn't that destructive to the semantics of the language if we had a function that was like "if, after this call, execution has not yet yielded, throw an exception wherever we currently are"
19:12
<bakkot>
I guess that would be bad for engines though, since they do keep track of which things might oom more carefully
19:19
<shu>
don't think i understand how that API works for something synchronous
19:19
<shu>
are you envisioning a timeout?
19:59
<bakkot>
yes, a timeout
19:59
<bakkot>
which when reached interrupts the currently executing thing
19:59
<bakkot>
and which gets automatically cleared whenever control is yielded to the event loop
20:00
<shu>
ah okay, yeah, i would not be against
20:00
<shu>
in practice engines already have to bake in interrupt checks for GC if nothing else
20:00
<shu>
the more intrusive change is to actually ensure there's a way to propagate termination
20:01
<shu>
every engine needs to propagate exceptions for throwing, but the default assumption is that such exceptions are catchable
20:06
<littledan>
Yeah I agree that this termination/timeout part is a common requirement