From 379096815648dfc9d007a33530016b9e58cef492 Mon Sep 17 00:00:00 2001 From: "M. J. Fromberger" Date: Tue, 12 Jul 2022 10:28:51 -0700 Subject: [PATCH] mempool: release lock during app connection flush (#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. --- internal/mempool/v1/mempool.go | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/internal/mempool/v1/mempool.go b/internal/mempool/v1/mempool.go index f797568c9..67c4c2858 100644 --- a/internal/mempool/v1/mempool.go +++ b/internal/mempool/v1/mempool.go @@ -131,6 +131,15 @@ 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 { + // 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(context.Background()) }