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

Forward isKindOfClass: to distant object? #155

Open
fumoboy007 opened this issue Sep 14, 2019 · 8 comments
Open

Forward isKindOfClass: to distant object? #155

fumoboy007 opened this issue Sep 14, 2019 · 8 comments

Comments

@fumoboy007
Copy link

Is there a reason we are not forwarding isKindOfClass: to the distant object? I think that would make the most sense since users are more likely to want to check the class of the actual object than of the proxy. FWIW, NSDistantObject forwards.

@wuhao5
Copy link
Collaborator

wuhao5 commented Sep 16, 2019

If we forward -isKindOfClass: One problem is that the Class will become a remote object on the receiving side and will never succeed. We can make Class pass-by-value, however, is there a way to know the class linked in two processes are the same if only given the name or is there any way to check class integrity/equality?

@fumoboy007
Copy link
Author

Good question. I don’t know the answer, but perhaps we can look at how Apple does it?

@wuhao5
Copy link
Collaborator

wuhao5 commented Sep 18, 2019

we can look at how Apple does it?

It is a little convoluted to digest, this is one of the sources we used to learn in the past. You are welcome to take a look and send the PR, I am happy to review.

@fumoboy007
Copy link
Author

Findings

  1. NSDistantObject calls -[NSConnection forwardInvocation:forProxy:], which calls -[NSInvocation encodeWithDistantCoder:passPointers:] with an NSPortCoder.
  2. I am assuming -[NSInvocation encodeWithCoder:] is called after that, which encodes the arguments using the coder.
  3. In NSPortCoder, the whole inheritance hierarchy is serialized.
  4. For each class, the class name and the class version are serialized.

@wuhao5
Copy link
Collaborator

wuhao5 commented Sep 18, 2019

Great findings, thanks!

What do you think of implementing it in eDO? To encode a class, we record the entire hierarchy and their respective versions; to decode, we find the class name and attempt to match its local version and hierarchy, right? this sounds a reasonable start. How do you think of a coincidental client that has the same entire hierarchy but a different implementation? I think this odd is super low, but it can happen too, right?

the other question, what is class version, how do we make sure it's well maintained?

@tirodkar
Copy link
Contributor

Thanks a lot for looking into this @fumoboy007. If class_getName can work across processes, then this would work for the cursory isKindOfClass comparison. My worry is how this would differ from an actual Class comparison itself.

@fumoboy007
Copy link
Author

Hmm not sure if we can really guarantee compatibility across processes. FWIW, Apple/GNUstep’s implementation just calls objc_lookUpClass. I don’t think it even checks the version or the hierarchy. If y’all are comfortable with doing that, I can implement it.

@wuhao5
Copy link
Collaborator

wuhao5 commented Sep 23, 2019

FWIW, Apple/GNUstep’s implementation just calls objc_lookUpClass.

After thinking about it, it should be fine because we are checking the class remote with a remote object. Suppose the client fakes a class by name, it would only cause the host to look it up.

If y’all are comfortable with doing that, I can implement it.

It will be great if you can implement it. Either Aditya, me or someone from our team can review it. There are another two things you might need to take a look:

  1. Class is handled differently by ARC, probably because it's static. you may need to pay extra attention to it.

  2. We have EDO_REMOTE_CLASS where you do need a remote Class, we need to make sure this behavior is not broken.

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

No branches or pull requests

3 participants