Open mkustermann opened 2 months ago
If we want to display which isolates are in which group, there's already enough information in the service for this (Observatory already displays it).
If we want to display the spawn tree, then the origin id doesn't capture that because the original id for every isolate in the group will be the first isolate in that group instead of the isolate that spawned it. The VM would need to start recording the parent somewhere.
If we want to display the spawn tree, then the origin id doesn't capture that because the original id for every isolate in the group will be the first isolate in that group instead of the isolate that spawned it. The VM would need to start recording the parent somewhere.
I must have misremembered this. @rmacnak-google Is there any use of the "origin id" concept (which then more or less means same isolate group)? We could then either make "origin id" to be "spawner id" or have both.
It's used to implement the check for a within-group message (sendport.originid == currentisolate.originid). Adding a "spawner Id" seems useful enough.
We should consider exposing the isolate spawn topolology in the
vm-service
protocol. That would allow debugging tools such as DevTools to display all isolates of an isolate group as a spawning tree (or forest, if some intermediary ones have died).The spawner of an isolate is the
originId
, if there was no spawner (the isolate wasn't created viaIsolate.spawn()
API) then it's the isolate's ownmainPort
id.One may also consider exposing on the isolate group object the isolate id of the first isolate in the group.
/cc @bkonyi