You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made a mistake while working on some comms integration, and convinced a vat to send messages to itself. Specifically, by getting an "ingress" and "egress" backwards, the receiving comms vat did a syscall.send({type:'export',id},...). Normally vats only use send to target {type:'import'}, but in this case the kernel cheerfully translateded the vat-local export into a sending-vat-specific export, and put it on the run queue just like any other message. Eventually the message was delivered to dispatch.deliver() back into the same vat from which it originated.
This was kinda confusing, and I don't think there's a good reason for vats to use the kernel to call back into themselves. So for now I'm going to disable these calls, and have the kernel throw an exception if a vat tries to send() to one of their own exports. It's conceivable that this will become a sensible thing to do in the future, when we get the escalator schedulers in place, but even then I'm not sure it will make sense.
The specific check is added to src/kernel/vatManager.js, in doSend().
The text was updated successfully, but these errors were encountered:
I made a mistake while working on some comms integration, and convinced a vat to send messages to itself. Specifically, by getting an "ingress" and "egress" backwards, the receiving comms vat did a
syscall.send({type:'export',id},...)
. Normally vats only usesend
to target{type:'import'}
, but in this case the kernel cheerfully translateded the vat-local export into a sending-vat-specific export, and put it on the run queue just like any other message. Eventually the message was delivered todispatch.deliver()
back into the same vat from which it originated.This was kinda confusing, and I don't think there's a good reason for vats to use the kernel to call back into themselves. So for now I'm going to disable these calls, and have the kernel throw an exception if a vat tries to
send()
to one of their own exports. It's conceivable that this will become a sensible thing to do in the future, when we get the escalator schedulers in place, but even then I'm not sure it will make sense.The specific check is added to
src/kernel/vatManager.js
, indoSend()
.The text was updated successfully, but these errors were encountered: