On Sat, Jan 31, 2009 at 10:15 PM, Robert Marini <wisequ...@gmail.com> wrote:
> Easily reproduced doesn't always translate into guaranteed to occur. In my
> experience, using a single queue in your application is a sufficient
> safeguard as no system framework I've encountered causes an issue.
Well, it turns out that this is not actually any sort of safeguard.
With the help of a persistent experimenter posting to my blog, I have
come up with this extremely simple test case:
#import <Foundation/Foundation.h>
@interface MyOperation : NSOperation {} @end
@implementation MyOperation
- (void)main
{
usleep(10000);
}
@end
int main(int argc, char **argv)
{
NSAutoreleasePool *outerPool = [[NSAutoreleasePool alloc] init];
NSOperationQueue *queue = [[NSOperationQueue alloc] init];
unsigned count = 0;
while(1)
{
NSAutoreleasePool *innerPool = [[NSAutoreleasePool alloc] init];
MyOperation *op = [[MyOperation alloc] init];
[queue addOperation:op];
[op release];
if(++count % 50000 == 0)
NSLog(@"%u operations", count);
[innerPool release];
}
[outerPool release];
return 0;
}
It crashes reliably on my Mac Pro. Note that it uses only one queue.
Note that it only enqueues operations from the main thread. Note that
it uses a very simple custom NSOperation subclass, and doesn't use
NSInvocationOperation at all. Note that it does nothing really
interesting or unusual in any way.
And yet it still crashes reliably on my computer, often before it can
even reach the 50,000 operation mark and print the first log line.
I will update my bug with Apple with this new, simplified test case.
For any Apple types reading along, it's rdar://6332143.
At this point, I can only recommend avoiding the entire API until and
unless the problem is fixed. It's true that it's weird and fairly
rare. It's true that your particular usage pattern may avoid it. Or it
may simply not have triggered it yet. It's hard to say either way, and
given the simplicity and the directness of the above test case, it
seems to me that counting on your code to avoid the trouble spot is
unrealistic.
Mike
_______________________________________________
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
