RedisConnection#Connect(): get rid of spin lock #10265
Conversation
Instead of IoEngine::YieldCurrentCoroutine(yc) until m_Queues.FutureResponseActions.empty(), async-wait a CV which is updated along with m_Queues.FutureResponseActions.
Al2Klimov
added
area/icingadb
| @@ -340,7 +334,7 @@ void RedisConnection::Connect(asio::yield_context& yc) | |||
| } | |||
|
|
|||
| Handshake(conn, yc); | |||
| waitForReadLoop(); | |||
| m_NoQueuedReads.Wait(yc); | |||
There was a problem hiding this comment.
I often struggle to differentiate between the AsioConditionVariable::Clear() and AsioConditionVariable::Set() methods since they seem to perform very similar functions, and neither of them includes a clear comment explaining their purpose. And yet, I had to trace on my own to understand why the init parameter is set for this in the constructor but not for the others. Could you please provide some comments explaining the scenarios in which this gets unblocked? Additionally, I would suggest naming that new property something like m_ReadLoopDone to better reflect its original intentions.
| @@ -577,6 +572,7 @@ void RedisConnection::WriteItem(boost::asio::yield_context& yc, RedisConnection: | |||
| } | |||
|
|
|||
| m_QueuedReads.Set(); | |||
| m_NoQueuedReads.Clear(); | |||
There was a problem hiding this comment.
Why not perform this within the ReadLoop method once m_QueuedReads.Wait() returns?
Instead of IoEngine::YieldCurrentCoroutine(yc) until m_Queues.FutureResponseActions.empty(), async-wait a CV which is updated along with m_Queues.FutureResponseActions.
👍 Re-connect still works on Redis restart, even if latter interrupted an outgoing message!
ref/NC/820479
claimed they start Icinga 2 with Icinga DB enabled – and it OOMs. I hope this spin lock is not responsible, but better safe than sorry.
Also, I'm sure we all agree that spin locks should be avoided, at least where easily possible.