| 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:
|
| 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 |