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.
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
