Re: autorelease question
Re: autorelease question
- Subject: Re: autorelease question
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 5 May 2006 08:42:36 -0700
On May 5, 2006, at 7:52 AM, Bill Bumgarner wrote:
My other question is, Do you think this solution would be better
handled with an NSTimer?
Yes. And it will manage a release pool for you. Actually, the
busy-loop-and-test-a-calendar-data method is fatally flawed in that
it uses CPU cycles when the thread isn't doing anything.
Let me expand this slightly.
When you spawn your thread, it will automatically have an NSRunLoop
created for it. You want to run the run loop. Run loops are
designed to:
- automatically create/release a release pool every pass through the
loop
- not actually pass through the loop unless one of the input event
sources requires processing; a timer goes off or a port is tickled
Now, if you really need to check for something every N seconds/
minutes/hours, then schedule a timer in that run loop that does
exactly that prior to telling the run loop to run. Given that you
are likely going to want to invalidate the timer at some point to
cause it to be removed from the runloop and, if it is the last event
source in the run loop, generally cause the run loop to stop running
(unless you explicitly cause the run loop to run forever), you'll
probably want something like:
Something like (this is Mail Code -- guaranteed to be rife with bugs
and not compile):
@interface MyWorkerBee:NSObject
{
NSTimer *everyNowAndThenTimer;
NSRunLoop *threadLoop;
NSThread *workerThread;
}
@end
@implementation MyWorkerBee
- (void) run
{
@synchronized(self) {
if (workerThread)
@throw .... exception indicating that you are already running ....
[NSThread detachNewThreadSelector: @selector("startThread:")
toTarget: self withObject: nil];
}
}
- (void) startThread: sender
{
@synchronized(self) {
workerThread = [[NSThread currentThread] retain]; // why not?
threadLoop = [[NSRunLoop currentRunLoop] retain]; // convenient
everyNowAndThenTimer = [[NSTimer alloc]
initWIthFireData: ....... ]; // do this to avoid release pool before
it exists in the run loop
[threadLoop addTimer: everyNowAndThenTimer forMode:
NSDefaultRunLoopMode];
}
[threadLoop run]; // do this after the lock on self is released --
will run as long as everyNowAndThenTimer is still active
}
@end
Now, if your timer is really intended to only be fired every fifteen
minutes to an hour to always do some work, then fine... go for it.
However, if the timer is being used to check to see if work is
available, then consider how you can cause "work is available" to be
a notification that causes the thread to wake up. Probably the
easiest way to do this across threads is to use distributed objects.
Note that NSPort subclasses are provided that can cause a run loop to
wake up in the face of socket activity (network traffic) or mach port
messages.
In any case, busy loops are so 1990s... don't go there.
b.bum
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden