Le 24 nov. 2010 à 05:53, Chris Hanson a écrit :
> If your code actually looks like this, it's a bug: You're using entityInMOC1
> in another thread. Pass JUST its object ID, not the object itself, from one
> thread to the other.
Well, it turns out it is caused by something else. But never mind,
Le 24 nov. 2010 à 05:53, Chris Hanson a écrit :
> If your code actually looks like this, it's a bug: You're using entityInMOC1
> in another thread. Pass JUST its object ID, not the object itself, from one
> thread to the other.
I had not thought about this. Thanks for pointing it out. I have n
On Nov 23, 2010, at 12:38 PM, vincent habchi wrote:
> However, I have now a repeated memory management crash when I release the moc
> (apparently, one managed object get released one time too much: it is
> destroyed in the main MOC, while the secondary MOC has a copy of it. When I
> release th
Chris,
thanks for your answer.
> Don't do this. If you're using bindings or KVO at all in your main thread,
> you CANNOT lock your context every place you need to in order to make this
> safe. Furthermore, I suspect you may not be locking your context on the
> background thread because you're
On Nov 22, 2010, at 1:08 PM, Quincey Morris wrote:
> On Nov 22, 2010, at 07:58, Hunter Hillegas wrote:
>
>> I think someone somewhere told me that if you create a MOC on the main
>> thread, there's some special runloop integration that is included, hence one
>> of the reasons it's important to
On Nov 21, 2010, at 11:47 AM, vincent habchi wrote:
> briefly speaking, I have a Core Data Entity bearing a to-many relationship
> (therefore an NSSet * iVar). A dialog on the main thread can modify this set,
> while it may be simultaneously enumerated on a background GCD thread. I have
> ther
On Nov 22, 2010, at 07:58, Hunter Hillegas wrote:
> I think someone somewhere told me that if you create a MOC on the main
> thread, there's some special runloop integration that is included, hence one
> of the reasons it's important to not create one on the main thread and then
> pass it aroun
I think someone somewhere told me that if you create a MOC on the main thread,
there's some special runloop integration that is included, hence one of the
reasons it's important to not create one on the main thread and then pass it
around.
This is also important to keep in mind re: NSOperation,
Quincey:
I am a bit in a hurry, so I will answer quickly:
> I think maybe you have more design options here. For example, you can [in
> principle, I think] multithread with a single MOC without locks if you pass
> "ownership" of the MOC around between threads that make changes, so that
> owner
On Nov 21, 2010, at 23:14, vincent habchi wrote:
> I intended to lock, fetch the entity, read the corresponding attribute, and
> unlock. That's all I've to do. On the main thread, I lock when I mutate the
> set, then unlock. That's all in one place, so it's not so difficult to figure
> out.
*T
Quincey:
> I think the point is that it's far *less* complex because the code to deal
> with a second MOC should be a lot simpler than the thread locking code. Plus,
> the chances are that your locking code is wrong. :) (Trust me, that's not a
> dig at you personally. But multithreading interlo
On Nov 21, 2010, at 12:50, vincent habchi wrote:
> Exactly, that's why I want to change. Note that my needs are fairly basic, so
> I didn't see the point of entering into a more complex scheme.
I think the point is that it's far *less* complex because the code to deal with
a second MOC should b
Le 21 nov. 2010 à 21:39, Quincey Morris a écrit :
> It's not an ivar, it's a property.
You're perfectly right.
> You can't modify a NSSet. I suspect you mean "modify this relationship", but
> the ambiguity leads me to wonder if you're trying to do something funky here.
> Not that it's relevant
On Nov 21, 2010, at 11:47, vincent habchi wrote:
> briefly speaking, I have a Core Data Entity bearing a to-many relationship
> (therefore an NSSet * iVar).
It's not an ivar, it's a property.
> A dialog on the main thread can modify this set,
You can't modify a NSSet. I suspect you mean "modif
Hi there,
briefly speaking, I have a Core Data Entity bearing a to-many relationship
(therefore an NSSet * iVar). A dialog on the main thread can modify this set,
while it may be simultaneously enumerated on a background GCD thread. I have
therefore used the managed object context provided mute
15 matches
Mail list logo
