-
Couldn't load subscription status.
- Fork 20
Create FileWatcher when ConfigManagingActor runs #1074
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
Create FileWatcher when ConfigManagingActor runs #1074
Conversation
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.
Other than that, LGTM.
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 think you should add a del file_watcher when the run finishes (including if an exception is raised), otherwise the file watcher internal task will keep running. Sadly it doesn't provide a stop() yet, I think we should add one, as using del is weird.
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 think it's no needed. The reference to the local file_watcher variable is gone once exiting the _run() method in the actor which will cause the file watcher internal task to be stopped when the object is collected. See here for more details
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.
Finalization is complicated. It is very likely that __del__ is called, but not guaranteed (if there is a cycle for example). This is why ideally we should probably have a stop() method and be more explicit about it.
I'm fine with leaving this as is, although I think it is always safer to do things explicitly to avoid surprises.
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 agree it's safer to explicitly delete the file_watcher then, will do it. I presume I'll need capture the error, delete file_watcher and re-raise the error
92b147f to
86b4213
Compare
|
Updated to explicitly delete |
| except (Exception, BaseException): | ||
| del file_watcher | ||
| raise |
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.
You are manually writing a finally 😆
| except (Exception, BaseException): | |
| del file_watcher | |
| raise | |
| finally: | |
| del file_watcher |
You could also use a ExitStack. Or we could make the FileWatcher a context manager (look ma, here it comes BackgroundService/Service again, if FileWatcher were a Service it would automatically be a context manager 😉), but I would leave that for the future as it requires a lot of work (changing FileWatcher, releasing etc.) and it should come automatically when we migrate channels to use core (and Service).
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 really forgot finally exists in python, somehow I only thought of try/except/else...sorry 👼
You could also use a ExitStack. Or we could make the FileWatcher a context manager (look ma, here it comes BackgroundService/Service again, if FileWatcher were a Service it would automatically be a context manager 😉), but I would leave that for the future as it requires a lot of work (changing FileWatcher, releasing etc.) and it should come automatically when we migrate channels to use core (and Service).
Agreed
The ConfigManagingActor was unable to process events after being restarted because the FileWatcher cannot be reused when the ConfigManagingActor is restarted, so we need to create a new instance every time the actor starts running. Signed-off-by: Daniel Zullo <[email protected]>
86b4213 to
90f0c60
Compare
The ConfigManagingActor was unable to process events after being restarted because the FileWatcher cannot be reused when the ConfigManagingActor is restarted, so we need to create a new instance every time the actor starts running.