-
Notifications
You must be signed in to change notification settings - Fork 229
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
Call Context._logging_fini() in Context.try_shutdown() #800
Conversation
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
@@ -101,8 +101,8 @@ def shutdown(self): | |||
# imported locally to avoid loading extensions on module import | |||
with self.__context, self._lock: | |||
self.__context.shutdown() | |||
self._call_on_shutdown_callbacks() | |||
self._logging_fini() | |||
self._call_on_shutdown_callbacks() |
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.
Is this ok to do with the lock acquired?
I was thinking maybe leave this outside the lock, leave the lock usage in fini logging but make it an rlock?
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.
Calling _call_on_shutdown_callbacks()
was supposed to be ok, as try_shutdown()
was already doing that.
But we were taking the locks in the opposite order in another place, so that doesn't look fine.
c9cba6a, c2f71b5 should fix it.
I was thinking maybe leave this outside the lock, leave the lock usage in fini logging but make it an rlock?
I prefer only using an rlock
when it's actually needed and not because of an implementation detail.
g_logging_configure_lock
is always locked after self._lock
, so there's no deadlock.
Doing all the shutdown process atomically keeping self._lock
held sounds like a good idea IMO.
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.
It looks like before this PR on_shutdown
and shutdown()
did not call callbacks with self._lock
acquired, while try_shutdown()
did.
Calling callbacks with self._lock
seems fine to me because the context is already shutdown when it's called. There doesn't seem to be a useful method on a shutdown context that a callback might want to call. However, it looks like that makes self._callbacks_lock
redundant. Anywhere self._callbacks_lock
is used self._lock
is already held.
I would recommend either making try_shutdown()
not call callbacks with self._lock
, or removing self._callbacks_lock
. I personally like the second option because it means one less lock to keep track of when reviewing PRs to Context
.
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.
However, it looks like that makes self._callbacks_lock redundant. Anywhere self._callbacks_lock is used self._lock is already held.
That's true
I would recommend either making try_shutdown() not call callbacks with self._lock, or removing self._callbacks_lock. I personally like the second option because it means one less lock to keep track of when reviewing PRs to Context.
Yes, that makes sense to me.
There's not much benefit of having two locks here.
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.
Done in d909a71
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
Fixes #518 (comment)