> On Oct 20, 2017, at 9:56 AM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > — When you scheduled the timer on the main run loop, it was actually being > scheduled on the main app’s run loop. When it was block based, only the block > had to be passed across the XPC interface (which somehow works), but when it > was selector-based, the timer itself had to be passed (which doesn’t work). > Admittedly this is a pretty silly explanation, but it may have some relation > to the truth.
That sounds plausible. One of the dangers of super-transparent inter-process messaging like XPC is that you can lose track of which objects are local and which remote, and end up using an object you thought was local but is just a proxy. Then you get either errors (as here) or terrible performance. True story from the early days of iChat: We were using Distributed Objects (the ancestor of XPC) to communicate between the iChatAgent process, which actually logs into the IM service, and the iChat app. One particular GUI operation was noticeably slow (I don’t recall which), and when we profiled it, we saw that it was making zillions of IPC calls. The reason turned out to be that we had assumed that NSURL objects got copied when sent between processes (the way NSStrings do), but actually they didn’t; they were proxied. So the iChat app ended up with a bunch of NSURL objects received from IPC calls, that it thought were local but were actually proxies. They behaved the same way as ‘real’ NSURLs, except that calling them was thousands(?) of times slower. —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
