processor: allocate #40
Conversation
program/src/processor.rs
Outdated
|
|
||
| macro_rules! accounts { | ||
| ( $infos:ident, $signers:ident, $( $i:literal => $name:ident ),* $(,)? ) => { | ||
| let mut $signers = HashSet::new(); |
There was a problem hiding this comment.
Is there a way to "predict" how many signers to expect? It would be better to have this as with_capacity to avoid reallocations – better yet if we can avoid using a std::collections::HashSet. 😉
There was a problem hiding this comment.
Yes, I think for all non-nonce instructions the number of signers is either 1 or 2. Perhaps I can rewrite this a bit.
There was a problem hiding this comment.
Let me know what you think of my latest commit!
| } | ||
|
|
||
| fn process_allocate(accounts: &[AccountInfo], space: u64) -> ProgramResult { | ||
| accounts!( |
There was a problem hiding this comment.
nit: I am wondering if there is a gain in using a macro over something like:
let [account_info, _remaining @ ..] = accounts else {
return Err(ProgramError::NotEnoughAccountKeys);
};There was a problem hiding this comment.
For a single account access, like in this instruction, no there's probably not much of a gain. But for the other ones coming up after this PR, I think it's worth doing.
| } | ||
|
|
||
| pub fn process(_program_id: &Pubkey, accounts: &[AccountInfo], input: &[u8]) -> ProgramResult { | ||
| match solana_bincode::limited_deserialize::<SystemInstruction>(input, MAX_INPUT_LEN) |
There was a problem hiding this comment.
I really don't want to, but for now, limited_deserialize is the de facto way to deserialize builtin entrypoints. That being said, this program doesn't seem to have unbounded instruction parameters (such as a collection), so we may be able to factor this out via pack/unpack methods on the instruction enum itself.
This PR implements the
Allocateinstruction processor in the BPF version of the System builtin program.See #38 for a draft overview of the implemented base processor (no nonce instructions).
As you can see from the comment within the
allocatefunction in the processor, we have immediately encountered one of two obstacles preventing us from migrating this program to BPF. Account resizing (realloc) in the VM is much more constrained than resizing in host memory, so we'll need to come up with a solution for expanding that.In the meantime, I think this should land with the current implementation, so we can begin implementing, profiling and testing the rest of program. For more context on account resizing, see #30.