-
Notifications
You must be signed in to change notification settings - Fork 35
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
Blocks cannot be serialized properly to remote objects due to load order bugs #157
Comments
We could actually implement those methods in One quick fix (probably the best fix) is, instead having a constructor, move the code into here using Do you want to try it out? |
Unfortunately, I have opted to implement an IPC solution of my own for our project with the needs of asynchronicity. I may be able to test in the future, but not right now. |
Kk, I'll send a quick fix in next few days then. |
Ummm... hi! I'd love to get that fix! |
As discussed in #156, it seems that blocks cannot be properly serialized to remote objects, when attempting a remote method call in a
+load
method, due to load order woes.The code linked in the other issue shows that
__attribute__((constructor))
is used, which is ordered later in the start chaing, after+load
methods.Moving the code to
+load
is also not the best solution, as+load
are also subject to call order issues, as I recently discovered. I've settled on nasty hacks in my case. But those hacks aren't suitable here, as the code is in a class category.The result is that when a block is called from the remote process, it is not serialized correctly on the client side (because the above-linked code has not executed yet), and an exception is raised
+[NSInvocation _invocationWithMethodSignature:frame:]: method signature argument cannot be nil
in:The text was updated successfully, but these errors were encountered: