Re: async NSOperation and NSOperationQueue
Re: async NSOperation and NSOperationQueue
- Subject: Re: async NSOperation and NSOperationQueue
- From: "Michael Ash" <email@hidden>
- Date: Tue, 16 Sep 2008 15:14:55 -0400
On Tue, Sep 16, 2008 at 12:50 PM, John Love <email@hidden> wrote:
> +++++
> Michael Ash wrote:
>
> When your application becomes unresponsive, pause it in the debugger
> and look at the backtraces of all the threads. (You can do this in a
> single step by typing "t a a bt" at the debugger console. This is a
> shortcut for "thread apply all backtrace".) This should quickly tell
> you where it's stuck, and thus hopefully why it's stuck.
> +++++
>
> t a a bt looks like it could be a powerful tool, but, Michael, I do not
> understand most of the following ..
I suggest you learn! Gdb is an extremely powerful, albeit difficult,
tool. Trying to write anything substantial without it is, in my
opinion, like a carpenter trying to build a house without using a
measuring tape. Maybe you can do it, maybe you can even do it well,
but it's going to take a lot more effort. Unlike the measuring tape,
gdb takes a fair effort to learn, but just like the measuring tape,
that effort pays off rapidly in the form of being able to work much
more efficiently. There are a lot of guides available online that talk
about how to use it.
> I see some familar stuff, such as
> MPWaitOnQueue and most of the listing at the very bottom .. but how is this
> trace tell me where the hang is?
If you in fact stopped the program while it was hung, then the trace
shows exactly what each thread was doing at the time. The main thread
(thread 0) is what handles the GUI, so you can see what it was doing
instead of handling the GUI.
As a really quick overview (hit up a tutorial for a more extensive
discussion), the backtrace shows the current call stack for each
thread. This call stack is read from bottom to top. For your backtrace
looking at thread 0, for example, you can see that start() called
NSApplicaitonMain(), which then called -[NSApplication run], and so
forth. You can follow it up into your code, and see what your code was
doing at the time. In this case -[ScriptController ExecAppleScript:]
appears to be executing an AppleScript, and that's what was happening
at the time you paused the debugger.
> I do see "Cannot access memory at address
> 0x0" with Thread3. Apparently, I've leaked memory or something rotten??
Gdb is occasionally unreliable. For some reason it was unable to
figure out the backtrace of this thread. I wouldn't worry about it
unless you see other symptoms.
> By the way, I init the Queue within the -init of the app controller. Then,
> in another method I go through a 100-count big for-loop, at each iteration
> of which I init a new NSInvocationOperation via:
> theOp = [[NSInvocationOperation alloc] initWithTarget:self
> selector:@selector(calculateWorksheetRow:) object:nil];
>
> followed by
>
> [theQueue addOperation:theOp];
>
> and then,
>
> [theQueue waitUntilAllOperationsAreFinished];
Has it occurred to you that waiting for the operation to finish is
rather at odds with the idea of trying to run it asynchronously to
keep your program responsive?
Mike
_______________________________________________
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