[3.2] Use block_num for interrupt of start_block #893
Conversation
…eceiving block before beginning of start_block
| @@ -1798,7 +1799,7 @@ producer_plugin_impl::start_block_result producer_plugin_impl::start_block() { | |||
| if( !remove_expired_blacklisted_trxs( preprocess_deadline ) ) | |||
| return start_block_result::exhausted; | |||
| if( !_subjective_billing.remove_expired( _log, chain.pending_block_time(), fc::time_point::now(), | |||
| [&](){ return should_interrupt_start_block( preprocess_deadline ); } ) ) { | |||
| [&](){ return should_interrupt_start_block( preprocess_deadline, pending_block_num ); } ) ) { | |||
There was a problem hiding this comment.
Here we are using pending_block_num defined as pending_block_num = hbs->block_num + 1;.
Is it the same as chain.pending_block_num();?
There was a problem hiding this comment.
Yes. Head is what we are building on and pending is what we are building. Therefore, pending is always head+1.
There was a problem hiding this comment.
Head is what we are building on and pending is what we are building
Hum, that would mean head = pending. What is head really? The last block we know about?
There was a problem hiding this comment.
Let me try that again. [block#3][block#4 head][pending... block#4 is a complete block. It is the head of the chain. pending is an incomplete block we are currently building.
There was a problem hiding this comment.
Oh, thanks, got you, I missed the on in building on in my first reading.
Signal received block with the block number so that
start_blockcan be interrupted even if the block is received before the start ofstart_block. This is particularly important for #867, but also useful as mitigation against race condition of receiving block right before start of the block in current implementation. See #648.Resolves #891