P2P: Signal controller to apply blocks if sync interrupted

[heifner]

It is possible due to an interrupt that the controller has stopped applying blocks. Give it a kick to make sure it continues.

I was not able to reproduce the problem, but looking at the logs I think this will fix the issue. Hopeful, to get feedback from reporter if this fixes the issue.

Resolves #1878

[greg7mdp]

hum, looking at the code I'm wondering if producer_plugin::process_blocks() has some possible unbounded recursion (probably not likely at all though).

[heifner]

hum, looking at the code I'm wondering if producer_plugin::process_blocks() has some possible unbounded recursion (probably not likely at all though).

The post starts a new thread stack. If it did dispatch then it could potentially be unbounded recursion.

[greg7mdp]

The post starts a new thread stack. If it did dispatch then it could potentially be unbounded recursion.

Yes, but the post calls process_incoming_blocks(process_incoming_blocks); which calls itself recursively, so just executing the posted task could cause a stack overflow right?

[heifner]

The post starts a new thread stack. If it did dispatch then it could potentially be unbounded recursion.

Yes, but the post calls process_incoming_blocks(process_incoming_blocks); which calls itself recursively, so just executing the posted task could cause a stack overflow right?

No.

process_incoming_blocks -> calls on_incoming_block, then calls post( process_incoming_blocks ), and then current stack ends

The post'ed task is picked up to execute:

process_incoming_blocks -> calls on_incoming_block, then calls post( process_incoming_blocks ), and then current stack ends

etc.

[greg7mdp]

How did I miss that. Thanks for pointing it out!