On Sep 22, 2010, at 16:45:51, Roland King wrote: > I did something similar to this a couple of weeks ago - posted about it but > under a heading about NSManagedObjectWillSave notifications. > > If you have a singleton with a method which returns an MOC, you can store the > MOCs you create in a CFDictionary in the singleton with the NSThread as key. > Then when asked to vend an MOC your singleton checks to see if there is one > for the current thread in the dictionary, if there is, returns it, else > creates one and puts it in the dictionary ready for next time. Now you don't > have to pass them around, just ask the singleton for one when you need it and > you'll get the right one. > > To clean them up the singleton registers for NSThreadWillExitNotification(s), > when it gets a notification it purges the entry for that NSThread from the > dictionary.
Seems reasonable. The only problem I foresee is that if the system is recycling threads for subsequent NSOperations, I don't think you'll get the NSThreadWillExitNotification, because the thread itself never exits. > > My MOC vendor is also a singleton so I just have a class method (called moc > because I got sick of typing) which does > > return [ [ self singletonObject ] managedObjectContext ]; > > Remember to protect the dictionary access piece with some kind of mutex so > only one thread is reading or writing it at a time. > > This has been working well for me. > > Roland > > On 23-Sep-2010, at 2:56 AM, Rick Mann wrote: > >> I knew that wasn't clear. We have a method on the singleton that returns an >> MOC. If the thread is the main thread, it returns the "main" MOC. If not, it >> creates a new MOC, and returns that. Then we subsequently pass that MOC >> around to the various methods responsible for doing the work of creating >> some objects. >> >> The problem is that passing it around is getting unwieldy. We want to just >> call the method to get the MOC in multiple places. To do that, we need to >> store it somewhere appropriate, and TLS was the most appropriate place, >> except that now I know it's not. The operation is actually not readily >> available, but won't be too hard to make so. >> >> If the NSOperation could've relied on getting a pristine threadDictionary, >> that would've been very convenient (more specifically, if it could rely on >> the NSOperation infrastructure to clean up the threadDictionary when the >> NSOperation finished, it would've been very convenient). >> >> On Sep 22, 2010, at 11:43:45, Kyle Sluder wrote: >> >>> On Wed, Sep 22, 2010 at 11:31 AM, Rick Mann <rm...@latencyzero.com> wrote: >>>> Pity. We have a singleton object that creates a subclass of NSOperation, >>>> which then calls back a method on the singleton that's intended to be run >>>> on a separate thread (provided indirectly by the NSOperation). That >>>> singleton needs it's own NSManagedObjectContext, which we were creating >>>> and then passing around to everything the singleton called. We wanted to >>>> avoid the danger of creating additional ones by storing it in TLS, but I >>>> guess we're not supposed to do that (although it does talk about data that >>>> you "create yourself or manage," which is the case here). >>> >>> You wanted to avoid the danger of creating additional >>> NSManagedObjectContexts? As far as I understand your design, you need >>> to create a new MOC for every NSOperation instance, regardless of what >>> thread it winds up being executed on. Theoretically, you'll never even >>> spawn another thread; you might be running on a Core Solo, and GCD >>> and/or NSOperationQueue might just run everything on the main thread. >>> >>> (I don't know if that's actually possible; GCD operations might always >>> run on a background thread, but I can certainly foresee the system >>> deciding not to create more than one background thread on a >>> single-core Mac.) >>> >>> --Kyle Sluder >> >> _______________________________________________ >> >> 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/rols%40rols.org >> >> This email sent to r...@rols.org > _______________________________________________ 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
