From cddddc832ecdd97f0059dabba5adc20b282f9d65 Mon Sep 17 00:00:00 2001 From: tnasu Date: Thu, 13 Jul 2023 18:03:08 +0900 Subject: [PATCH] mempool: release lock during app connection flush (#8986) A manual backport of #8984. This case is symmetric to what we did for CheckTx calls, where we release the mempool mutex to ensure callbacks can fire during call setup. We also need this behaviour for application flush, for the same reason: The caller holds the lock by contract from the Mempool interface. Co-authored-by: M. J. Fromberger --- mempool/v1/mempool.go | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/mempool/v1/mempool.go b/mempool/v1/mempool.go index b3514235a..519e295bc 100644 --- a/mempool/v1/mempool.go +++ b/mempool/v1/mempool.go @@ -131,7 +131,18 @@ func (txmp *TxMempool) SizeBytes() int64 { return atomic.LoadInt64(&txmp.txsByte // // The caller must hold an exclusive mempool lock (by calling txmp.Lock) before // calling FlushAppConn. -func (txmp *TxMempool) FlushAppConn() error { return txmp.proxyAppConn.FlushSync() } +func (txmp *TxMempool) FlushAppConn() error { + // N.B.: We have to issue the call outside the lock so that its callback can + // fire. It's safe to do this, the flush will block until complete. + // + // We could just not require the caller to hold the lock at all, but the + // semantics of the Mempool interface require the caller to hold it, and we + // can't change that without disrupting existing use. + txmp.mtx.Unlock() + defer txmp.mtx.Lock() + + return txmp.proxyAppConn.FlushSync() +} // EnableTxsAvailable enables the mempool to trigger events when transactions // are available on a block by block basis.