I am a bit confused on the difference between using an actor class to create a canister vs. using the IC Management canister to create a canister (IC.create_canister()) and then using the install_code() function to load in the WASM.
Is the biggest difference just that with actor class you do not need to also install the WASM, making it simpler to create new canisters dynamically? Is a canister created using an actor class COMPLETELY separate from the canister that created it (Has its own 4GiB of Heap Memory and does not take up any memory in the parent actor)? Is there any drawback using an actor class vs IC.create_canister()?
Also, once a canister is created dynamically what is the best way to go about upgrading them?
Is the biggest difference just that with actor class you do not need to also install the WASM, making it simpler to create new canisters dynamically?
Yes.
Is a canister created using an actor class COMPLETELY separate from the canister that created it (Has its own 4GiB of Heap Memory and does not take up any memory in the parent actor)? Is there any drawback using an actor class vs IC.create_canister()?
Yes, it’s completely separate canister (compiled with the same flags as the main actor).
The actor that instantiates the class is the controller of the instance (IIRC).
The main drawback is that the wasm for the canister is embedded in the wasm of the importing actor or actor class, bloating the main actor a bit, and you cannot vary the compiler arguments (e.g. the parent and child will use the same gc algorithm, for example).
Also, once a canister is created dynamically what is the best way to go about upgrading them?
Yes, that’s a bit tricky, but there is some support for that (we still need write up some tutorial style documentation though).
Related links:
Post:
Reference documentation
3 Likes