Skip to content

Conversation

@stealthybox
Copy link
Member

@stealthybox stealthybox commented Apr 30, 2025

Functionally, this is similar to #757 but implemented with a Mutex instead.

See the diff from the second commit in this PR.

Perhaps this is a more legible way of handling the GC state.
It does also give us some other options for yeilding the GC to the controller's signal interrupt.

Related #748

Comment on lines +58 to +60
gc.running.Lock()
gc.discardValueLogFiles()
gc.running.Unlock()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, what if we only locked within the loop-body of discardValueLogFiles()?
Then the GC would stop work for each discard, and the controller could exit sooner -- it's an edge case and would require a little bit more sync with Stop().

@stealthybox
Copy link
Member Author

Closing this.
Stefan suggested the GC should shut down more proactively on SIGTERM instead of waiting for all of the controller manager to shut down first like we do when closing the database.
I realized then that I could just add the GC to the controller manager by implementing the Runnable interface.

Carrying forward in #757

@stealthybox stealthybox closed this May 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant