-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RedisConnection#Connect(): get rid of spin lock #10265
base: master
Are you sure you want to change the base?
Conversation
lib/icingadb/redisconnection.cpp
Outdated
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
The current implementation is rather similar to Python's threading.Event, than to a CV.
Instead of IoEngine::YieldCurrentCoroutine(yc) until m_Queues.FutureResponseActions.empty(), async-wait a CV which is updated along with m_Queues.FutureResponseActions.
c0dd426
to
fd24514
Compare
@@ -145,14 +145,14 @@ class TerminateIoThread : public std::exception | |||
}; | |||
|
|||
/** | |||
* Condition variable which doesn't block I/O threads | |||
* Awaitable flag which doesn't block I/O threads, inspired by threading.Event from Python |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see the updated docs of the class in question.
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.