• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Comment on NSThread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comment on NSThread


  • Subject: Re: Comment on NSThread
  • From: Nathan Day <email@hidden>
  • Date: Wed, 17 Jul 2002 20:45:09 +0930

On Wednesday, July 17, 2002, at 01:14 AM, Kirk Kerekes wrote:

If the inability to actually release an NSTimer bugs you (as I know it bugs me), consider going a step lower to NSObject's

You can release a NSTimer if retain it first of cause, just like any other object you don't create yourself, though it will not have any effect since somebody else has retained it also, most likely NSRunLoop. When NSRunLoop releases the NSTimer is it's business as long as it's after the NSTimer has been invalidated or is not due to fire anymore. Of cause if you want to do anything with the timer like invalidate it you should retain it otherwise NSRunLoop could release it from under you and you are trying to send messages to an object that no longer exists.


- (void)performSelector:(SEL)aSelector withObject:(id)anArgument afterDelay:
(NSTimeInterval)delay

and

- (void)performSelector:(SEL)aSelector withObject:(id)anArgument afterDelay:
(NSTimeInterval)delay inModes:(NSArray *)modes

-- which I infer contain NSTimer's core functionality.


Looking an the documentation to performSelector:withObject:afterDelay:inModes: it seems to me that these are simply convenience methods to create a NSTimer, the invalidate link in the doc is to NSTimers invalidate method.
When I looked briefly at GNU Steps NSRunLoop the way timers seem to work is that the NSRunLoop keeps a pool of the, as well as waiting for some input it waits for the time interval specified in the earliest NSTimer due to fire, when the time is up the NSRunLoop looks in it's pool of NSTimers to see if there are any due to fire and then tells them to do so. Thats why releasing an NSTimer doesn't do anything it's because the NSRunLoop owns the NSTImer also. Invalidating a NSTimer flags it in some way as no longer needed and so NSRunLoop probable releases it sometime after that, perhaps when it was next due to fire or perhaps straight away.

Nathan Day
http://homepage.mac.com/nathan_day/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Comment on NSThread (From: Kirk Kerekes <email@hidden>)

  • Prev by Date: Re: OS 9 Extension...
  • Next by Date: Re: Fire events
  • Previous by thread: Comment on NSThread
  • Next by thread: What do do with my life?
  • Index(es):
    • Date
    • Thread