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

Simplify how we determine whether to embargo #212

Merged
merged 1 commit into from
Jan 3, 2022

Conversation

zenhack
Copy link
Contributor

@zenhack zenhack commented Jan 2, 2022

Rather than having recvCap deal with this directly, we now have a separate
routine that just checks if a client is local, which we invoke higher up
in the chain.

This means we're not trying to figure this out based on the cap
descriptor, which means (1) fewer cases, and (2), in the case of
a cap descriptor that denotes a promise or answer, we will be able
to recursively call this on the target -- whose original CapDescriptor
may not be known.

This introduces one minor functional change: ErrorClients are now
treated as local. This means we'll set up embargos for them, which
we don't need to do, but it shouldn't be a problem; calling methods
on errors is not a case that is terribly sensitive to the extra round
trip. We could try to rework ErrorClient to avoid this, but it doesn't
seem worth the trouble.

Rather than having recvCap deal with this directly, we now have a separate
routine that just checks if a client is local, which we invoke higher up
in the chain.

This means we're not trying to figure this out based on the cap
descriptor, which means (1) fewer cases, and (2), in the case of
a cap descriptor that denotes a promise or answer, we will be able
to recursively call this on the target -- whose original CapDescriptor
may not be known.

This introduces one minor functional change: ErrorClients are now
treated as local. This means we'll set up embargos for them, which
we don't *need* to do, but it shouldn't be a problem; calling methods
on errors is not a case that is terribly sensitive to the extra round
trip. We could try to rework ErrorClient to avoid this, but it doesn't
seem worth the trouble.
Copy link
Collaborator

@lthibault lthibault left a comment

Choose a reason for hiding this comment

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

LGTM. The readability improvement is significant.

@lthibault lthibault merged commit 9b2b31e into capnproto:main Jan 3, 2022
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