Hi Miles,
On Tue, May 5, 2009 at 11:54 AM, Miles <vardpeng...@gmail.com> wrote:
> 1) I have a timer on a run loop. Every so often I invalidate the timer which
> as I understand it should remove the run loop as well.
No, invalidating a timer just removes it as a source from the run loop.
> At a later time I
> start a new run loop (by calling the same method as before), then invalidate
> that timer after a while, and repeat.
There is at most one run loop per thread. What I think you mean is
that you start a new thread.
> When I pause the debugger after this happens a few times I notice that
> sometimes the run loop threads have been successfully removed and sometimes
> not. I should only ever see one at most, but sometimes I see two or more.
> The timer in the extra threads hanging around are not running because it
> would be obvious in my app if that was happening. I have an autorelease pool
> around the code that creates and starts the run loop but I’m not sure it’s
> doing anything.
>
> My question is, what might be keeping the extra run loop threads around on
> occasion?
You can't rely on a runloop stopping just because you've removed a
timer. Other things might have added themselves as sources to the run
loop. If you want to force the run loop to stop, I think you can call
CFRunLoopStop, or follow the example shown in the -[NSRunLoop run]
method documentation.
> Here's the important code:
[snip]
Unless there's a serious amount of work going on in doTileAnimation:
there's no need for the extra thread; just keep it on the main thread.
By the way, doTileAnimation isn't doing any UI stuff is it? That's
generally not a good idea.
Also, I presume you'll neve call startAnimation before calling
stopAnimation; you'll lose track of the old timer otherwise.
> 2) My second question is, from within that run loop, is it safe to make a
> copy of an array that’s in the main thread like this?
You mean, "…from within that thread…". Run Loop != Thread.
> NSMutableArray *tmp = nil;
> NSLock *theLock = [[NSLock alloc] init];
> if( [theLock tryLock] ) {
> tmp = [NSArray arrayWithArray:animatingTilesArray];
> [theLock unlock];
> }
>
> On occasion I have gotten an error on the line where it tries to make a copy
> of the array. animatingTilesArray and tmp are both of type NSMutableArray
> The errors were things like ‘attempt to insert nil object at objects[0]'
> (but when I looked at animatingTilesArray it had several non-nil objects in
> it. I think I saw another error there but I can’t remember now what it was.
If you're going to do that, you have to use the same lock wherever you
are manipulating animatingTilesArray. It doesn't look like you're
doing it since I can see where you're allocating the lock.
I'm getting the impression you haven't done a lot of threaded
programming so I suggest you read up on it a bit. Presumably, you want
to use threads because of some performance problem you're having. Have
you actually measured things to see if there is a performance problem?
As I said, you might not need to use threads at all if doTileAnimation
isn't that intensive.
Regards,
Chris
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
