So, let me clarify further:

Someone asked why a save operation would take a few seconds. I can answer that 
I have an object model that is stored in ram and then serialized to disk. I 
should have started the data model as a Coredata project, but decided not to 
since my datasets would never be that big. The case when a save operation takes 
5-10 seconds is an extreme case that occurs on older G4 machines. I work in a 
facility with over 100 macs that still run on 10.4. Upgrades (particulaty for 
additional software) are a big cost to the company.

As for NSRunLoop, let me see if I understand. I have created a new Thread with 
[NSThread detachNewThreadSelector:toTarget:withObject:]. The selector is a do 
loop that periodically calls a custom NSView's redisplay method that invokes 
[NSView setNeedsDisplay:YES]. I should invoke this using 
performSelectorOnMainThread. Is there a mode that I can set on the main 
thread's NSRunLoop that allows my calls to be invoked?

Patrick


On Feb 1, 2010, at 9:34 AM, Corbin Dunn wrote:

> 
> On Feb 1, 2010, at 8:57 AM, Jens Alfke wrote:
> 
>> 
>> On Feb 1, 2010, at 7:20 AM, Kyle Sluder wrote:
>> 
>>> So in your override of -writeToURL:…, spin off the background thread like I 
>>> suggested, then set up your UI, and then start running the runloop in a 
>>> special modal mode until your background thread is done.
>> 
>> Nested runloops like this are usually a "code smell", an indication that 
>> you're trying to shoehorn asynchronous code into a synchronous caller, and 
>> should instead refactor the calling code to be async too. However, if you're 
>> implementing NSDocument's abstract save functionality, you can't do a lot 
>> about that.
> 
> Actually, that points out a problem in our API. It would be beneficial if 
> there was a version of writeToURL that automatically happened asynchronously 
> from a background thread. Don't forget to log feature requests for stuff like 
> this when you encounter problems like these.
> 
> -corbin
> 
>> 
>> Pay attention to Kyle's advice to use "a special modal mode". If you run the 
>> runloop in a normal mode, then your app can handle incoming events while in 
>> this loop and dispatch them to your code — this often leads to unexpected 
>> re-entrancy that can cause bizarre and hard-to-debug problems. (It's 
>> happened to me more than once.) Nowadays I always make sure that, if I have 
>> to use a nested runloop, I make up my own unique mode name to run it in.
>> 
>> (BTW, it seems a little odd to me that it takes so long to save documents in 
>> your app. Have you tried profiling your save implementation to see if it can 
>> be made faster? Most apps save nearly instantaneously.)
>> 
> 

_______________________________________________

Cocoa-dev mailing list ([email protected])

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to