• 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: Subclassing NSNotificationCenter
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subclassing NSNotificationCenter


  • Subject: Re: Subclassing NSNotificationCenter
  • From: Chris Kane <email@hidden>
  • Date: Wed, 24 Sep 2003 13:14:42 -0700

On Sep 4, 2003, at 6:58 AM, Neil Earnshaw wrote:
I need to subclass NSNotificationCenter so that I can provide a -removeObserver:selector:name:object: method (note the selector: in there).
[...]
Has anyone out there successfully subclassed NSNotificationCenter or NSNotificationQueue?

It is practically impossible to subclass NSNotificationCenter without overriding all the methods and implementing all the storage and sending yourself.

And getting this right and satisfying all the constraints on the system (which are documented nowhere except in various [third-party and Apple] peoples' experience) is EXTREMELY complex. You need to be thread-safe and re-entrant (recursive-safe), for starters, but removes need to take effect immediately, even if posting is going on another thread. [Why? Simple example: many people do a removeObserver:self in the -dealloc method of an object, which means that object is going away and future and imminent postings to that observer that may be going on in another thread need to be avoided. There's no way to completely eliminate the race though.] And you also need to be concurrent, you can't block in the remove case because posting is going on in another thread, to "wait for that to finish" -- that can lead to deadlocks as we found with NSNotificationCenter in 10.2 and previous, though they're not often hit. I'm not sure a data structure which employs some form of mutex locking can properly avoid all the pitfalls, and Apple has had a number of tries at it over the years. In Panther we've given up on mutex locking for yet another try, but the implementation is out on the frontiers of computer science.


Does anyone know how I can insert my own notification queue into the event loop so that it gets to process notifications each event cycle the way NSNotificationQueue does?

The perfom....afterDelay: method can be used sometimes for this (but repetively performing and cancelling is a performance lose -- don't do that). Or the -perform...order:... methods in NSRunLoop.h. Or override -sendEvent: or other method in a custom subclass of NSApplication. It all depends on what you mean by "each event cycle" and at what point you want to do your stuff.


Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
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: 
 >Subclassing NSNotificationCenter (From: Neil Earnshaw <email@hidden>)

  • Prev by Date: Re: NSTextFieldCell subclass
  • Next by Date: Cocoa Java: this class is not key value coding-compliant
  • Previous by thread: Subclassing NSNotificationCenter
  • Next by thread: Generating Unique ID
  • Index(es):
    • Date
    • Thread