Move checkpoint for auto-requeue on SLURM clusters out of signal handlers #21407
+169
−173
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
martenlienen
requested review from
ethanwharris,
justusschock,
lantiga and
tchaton
as code owners
martenlienen
force-pushed
the
slurm-signals
branch
2 times, most recently
from
7f19428 to
ac50dbd
Compare
Signal handlers are a precarious environment, because they can be called at any time, for example in the middle of another function. So performing IO in there can lead to difficult to track down errors. This change moves the heavy lifting of requeuing into the normal life cycle of lightning loops.
martenlienen
force-pushed
the
slurm-signals
branch
from
ac50dbd to
f0c2c47
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR changes
_SignalConnectorso that SIGTERM and the requeuing signal now only set a flag that is checked at the next possible point in the normal lifecycle of lightning's loops, i.e. in the next call to any callback hook. This way it is guaranteed that the program will always be in a well-defined state when the checkpoint is created and there is no danger of crashes from IO in signal handlers.Fixes #21406
There is only one technically breaking change:
_SignalConnectornow also composes with signal handlers for the requeue signal, not just SIGTERM. I looked through issues linked in commits to this file but did not find a justification why this should only happen for SIGTERM.Before submitting
PR review
Anyone in the community is welcome to review the PR.
Before you start reviewing, make sure you have read the review guidelines. In short, see the following bullet-list:
Reviewer checklist
📚 Documentation preview 📚: https://pytorch-lightning--21407.org.readthedocs.build/en/21407/