Bitcoin full node and query server

May 3, 2024

View in context in the libbitcoin Slack #general mirror.

evoskuil18:43
Also discovered a race in the node backup implementation that can result in a deadlock. The node broadcasts a pause event so that network traffic halts, and then waits until there are no outstanding writes by waiting on a database write lock. But new channels often pop up and have not received the event, resulting in a log wait (until there is no actual write traffic). It's similar to the shutdown wait, but that's safe because it permanently terminates all channels.
2 replies · evoskuil · last May 05, 2024
evoskuil15:21
*long wait
evoskuil15:53
Resolved this, just placed a pause event rebroadcast in the backup event handler in the case of a wait_lock event. The wait_lock signals that store write exclusivity was not obtained for a full second and will retry. Resending the pause event suspends any channels that may have missed it on the initial send. This does technically present a halting problem, since that back and forth can theoretically go on forever, but that's extremely unlikely. If it did for some reason happen, all that occurs is the backup is deferred until store close, which suspends all channels, resulting in backup obtaining the lock, completing the snapshot, and then close obtaining the lock. So a simple one line good solution to a tricky race condition.
(edited)
🙌 1