-
Notifications
You must be signed in to change notification settings - Fork 537
Solving the race conditions for logging #3855
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
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
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.
@bcdurak Did you by any chance run some tests to see if this slows down the logging in any considerable way?
@schustmi I am running the stress test now. Will merge if everything is in the green. |
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.
In general this is written in a way that makes it very hard to grasp what is happening, as there is so much locking happening in so many places.
Wouldn't it be much simpler like this? Obviously very simplified:
def write(...):
buffer_to_write = []
with self.buffer_lock:
self.buffer.append(...)
if self.should_write():
buffer_to_write = self.buffer.copy()
self.buffer = []
self.last_merge_time = time.time()
if buffer_to_write:
self._write_data(buffer_to_write)
And then have the io_lock
in _write_data
? Of course we would still need to make sure the threads enter the io_lock
in the correct order, and this doesn't cover the merging yet. But I feel like it would be much clearer, wdyt?
Exactly what I have been struggling with. This way, it would have been much simpler but you pointed out the main problem. If there are two threads that finishes the buffer process (and they want to write the buffer to the file), it is possible for the for the order to get messed up. I am trying a solution where the process picks up the While I was playing around with it, I have discovered other problems as well:
|
@schustmi I have pushed the idea that I had in mind. The code is still in a bit of a dirty state, but feel free to take a look. |
@schustmi, I revamped the whole thing. Feel free to take a look. |
Describe changes
I implemented/fixed _ to achieve _.
Pre-requisites
Please ensure you have done the following:
develop
and the open PR is targetingdevelop
. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.Types of changes