Re: Isolated process for each NSDocument of my app
Re: Isolated process for each NSDocument of my app
- Subject: Re: Isolated process for each NSDocument of my app
- From: Jens Alfke <email@hidden>
- Date: Fri, 14 Jun 2013 10:17:19 -0700
On Jun 14, 2013, at 1:15 AM, Daniele Margutti <email@hidden> wrote:
> No offence guy, but seriusly I can’t. We have a compatible UIKit layer which can run on OS X. In order to mantain compatibility I need to handle UIApplication and UIScreen singleton; morehower I need to manage UIAppearance. This thing can’t work on with multiple projects at the same time so in order to work with it I need to isolate each project/UIKit instance/process from the other.
I’m going to ignore the issue of whether it even makes sense to try to bash code and UI designed for iOS into running on Mac OS. Apps that are ported across platforms by brute force this way rarely work well.
At a technical level, I think your best bet is to use state-switching. Use a model where one app instance is active at a time. Each one has its own instances of the singletons (UIApplication, etc.) and when an app instance is active, the singleton accessors like [UIApplication application] return the object matching that app instance.
Now you have only one piece of global state, the current-app-instance. What you need to do is switch that appropriately based on which app is going to be running next. The obvious thing is before handing an event, determine which app it’s aimed at (probably based on which app owns the appropriate NSWindow) and set that one.
The harder task is to set the current-app when other runloop-based calls happen, like timers and delayed-performs and NSURLConnection delegate calls and so forth. Wrapping all of those APIs would be a real pain.
One possible solution is to create a new thread with its own runloop for each app instance, and always run it on that thread. Then in fact you can resolve all your singletons by using the NSThread dictionary to look up state. You just have to handle events by looking up the target app’s thread, posting the event to that thread’s runloop, and then blocking till it completes. (This also avoids trouble with thread-safety because it ensures that only one of those app UI threads can be handling UI events at a time.)
This still sounds challenging, but it’ll be a million times easier than trying to run multiple processes.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden