Skip to content
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

router: track endpoints more explicitly #19554

Merged

Conversation

allisonkarlitskaya
Copy link
Member

No description provided.

Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

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

Thanks! The purpose of this is a bit vague, but I understand this is preparatory stuff for the really interesting bits 😁

src/cockpit/beiboot.py Outdated Show resolved Hide resolved
src/cockpit/router.py Show resolved Hide resolved
src/cockpit/router.py Show resolved Hide resolved
The router currently keeps a mapping of open channels to the endpoints
responsible for them.  This presents two problems:

 - when we close down an endpoint, we need to iterate all open channels
   in order to determine which channels belong to that endpoint
 - it's possible to have active endpoints associated with the router
   which the router has no idea about

Move to a more explicit model where we add a second mapping: endpoints
to their set of open channels.  This makes endpoint shutdown easier and
adds the advantage that an endpoint with no channels can still be
tracked by the router (with an empty channel list).

The second point of this will be useful in future commits when the
router (and not the routing rules) become responsible for ensuring that
all endpoints are correctly shutdown.

We need to adjust the beiboot code a bit to avoid a catch22 whereby the
routing rule needs to exist before the router is initialized, but the
Peer itself can only now exist after the router is initialized.
It's theoretically possible that the user might send multiple 'close'
messages to a D-Bus channel, which would have a chance to be delivered
because the channel doesn't close immediately (but rather waits for
outstanding requests to complete).

This is a pretty theoretical bug but it's going to get worse when we
modify how the router shutdown works in the next commit.
Add a .do_close() virtual method at the Endpoint level.  This is already
implemented by Channel, but let's also add an implementation of it to
Peer which shuts down the Peer in the usual way.

When the bridge gets EOF we can now call this method on all endpoints
instead of creating synthetic close messages for each channel.  We also
stop tracking open channels for knowing when the shutdown is complete,
and track endpoints instead (which is a strictly tighter constraint, as
it includes endpoints with no open channels).

There's the small matter of the increasingly redundant shutdown() method
on routing rules, but we can clean that up soon.
Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

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

Thanks! That's clearer now.

@allisonkarlitskaya allisonkarlitskaya merged commit d1b4f18 into cockpit-project:main Nov 10, 2023
93 checks passed
@allisonkarlitskaya allisonkarlitskaya deleted the endpoint-close branch November 10, 2023 08:58
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.

2 participants