Description
Currently if you call ChannelManager::get_and_clear_pending_events
while serializing out the ChannelManager
you can race - clearing the pending events, writing the channelmanager out, then crashing before having handled the events, thus potentially losing them.
Previously, I'd thought about adding an event handling function in lightning_background_processor::BackgroundProcessor
so that we default to a single loop which handles events and serializes the ChannelManager
, avoiding many of the issues. See also the issue on the sample client about this - lightningdevkit/ldk-sample#4 (comment), one thing we'd ideally like to support is for a tokio client to process many of the events in an async context, allowing them to use async functions instead of relying on our sync API. It may be possible to keep our synchronous API, but have users call some method to spawn futures in a tokio context which exists outside of the background processor thread, and then have the background processor thread block_on
those futures completing, but I'm not sure if tokio supports it.
Still, while this approach should help significantly, but there is a second race that is much trickier to fix - we can end up where users process an event, store something about it to disk, then crash before re-serializing the ChannelManger
, resulting in duplicate processing.