On Aug 25, 2011, at 12:15 AM, Jerry Krinock wrote: > I discovered a bug in my app today caused by the following repeatable > behavior: When one particular NSInvocationOperation in an NSOperationQueue > executes, two others get whacked out of the queue, and thus never execute.
> All but three of the operations are instances of my own subclass of > NSOperation. Indexed starting with 1, these operations, numbers 17, 32 and > 40, are NSInvocationOperations. Although all three of the subject > invocations invoke the same target (which happens to be the operation queue) > and the same selector, the three invocations are different objects, and the > three invocation operations are different objects. > Fortunately, NSInvocationOperation is only a convenience, and by simply > replacing these operations with instances of my own NSOperation subclass, the > problem was fixed. > > Can anyone take a stab at explaining this? At a guess, the NSOperationQueue may be dequeuing operations using something like -[NSMutableArray removeObject:] instead of -[NSMutableArray removeObjectIdenticalTo:]. Thus, it is depending on -isEqual:. I further guess that NSInvocationOperation objects with identical targets and selectors compare equal. Definitely sounds like a bug. You could test by a) subclassing NSInvocationOperation to change its equality semantic and seeing if the problem goes away, and b) seeing if you can reproduce with a custom NSOperation subclass which implements equality based on value and not identity. Regards, Ken _______________________________________________ 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
