Skip to content

Conversation

@ivanpauno
Copy link
Member

Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
@ivanpauno ivanpauno added the enhancement New feature or request label May 28, 2021
@ivanpauno ivanpauno requested a review from wjwwood May 28, 2021 21:08
@ivanpauno ivanpauno self-assigned this May 28, 2021
@ivanpauno ivanpauno added bug Something isn't working and removed enhancement New feature or request labels May 28, 2021
self.__context.shutdown()
self._call_on_shutdown_callbacks()
self._logging_fini()
self._call_on_shutdown_callbacks()
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done in d909a71

ivanpauno added 3 commits May 31, 2021 18:27
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
Signed-off-by: Ivan Santiago Paunovic <ivanpauno@ekumenlabs.com>
@ivanpauno
Copy link
Member Author

CI:

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@ivanpauno ivanpauno merged commit ad22613 into master Aug 18, 2021
@delete-merged-branch delete-merged-branch bot deleted the ivanpauno/try-shutdown-should-fini-loggers branch August 18, 2021 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants