IRC channel logs
2025-03-17.log
back to list of logs
<jfred>Interesting finding re: nesting `with-vat`. I'll have to read through the rest of this later, looks interesting! <dthompson>jfred: yeah you basically never want to nest with-vat calls <dthompson>with-vat gets you into the context of a vat and once you're in you do not need to do that again <dthompson>(with-vat foo (with-vat foo (+ 1 2 3))) causes a deadlock because with-vat suspends the current fiber until a result is returned <dthompson>so that inner with-vat call is suspending the vat loop! <dthompson>(with-vat foo (with-vat bar (+ 1 2 3))) doesn't necessarily cause a deadlock because it uses 2 different vats <dthompson>vat foo will be suspended until the results of the inner with-vat are returned <dthompson>this was why andreas was having serious performance issues before <dthompson>we should just throw an error in this case. it's an easy mistake to make and it's not clear why it's a problem to new users. <dthompson>is that the case where you have an actor that spawns vats? <dthompson>I call these higher-order vats and it's a good point that you've raised. I don't think my solution of just throwing an error is going to be sufficient. <dthompson>because if an actor spawns a vat, you *need* at least one with-vat to spawn something in it. <dthompson>maybe the behavior needs to be dynamic. if you're in a vat, return a promise. if you're not in a vat, suspend the fiber. <jfred>does the persistent vat mechanism (where you pass an init thunk to run initially) use with-vat under the hood? <dthompson>I think it uses a "system op" which is what with-vat uses <dthompson>having a reference to a vat gives you the privilege of injecting work into the queue like this <jfred>returning a promise if running inside a vat feels reasonably clean