Re: Sublclassing NSThread
Re: Sublclassing NSThread
- Subject: Re: Sublclassing NSThread
- From: Robert Marini <email@hidden>
- Date: Wed, 17 Dec 2008 11:26:32 -0500
There are a great many more bugs than what Mike described in the
previous thread relating to NSOperationQueue - it leaks Mach Ports
under GC, it occasionally will retain an operation object if you
cancel before starting it, it will sometimes dealloc an operation
object without updating finished, on iPhone it doesn't like adding
operations to the queue from anything but the main thread (this is
separate from the invocation operation issue as previously discussed),
etc. Then there are just the simple quirks - .e.g -operations returns
an array of running operations (rather than all operations added to
the queue, which isn't made terribly clear in the docs). At the end
of the day, I find myself spending more time getting NSOperationQueue
to behave than I do in the core components of an application.
Yes, there is almost always a workaround (as of late I've grown fond
of storing a custom operation object in an array and spawning
invocation operations for each with my own concurrency metric and
pushing them onto the queue though that obviously defeats much of the
point of the API) but one should not rely on workarounds.
-rob.
On Dec 17, 2008, at 11:14 AM, Keith Duncan wrote:
On 17 Dec 2008, at 15:41, Jean-Daniel Dupas wrote:
because there's absolutely no way to guarantee that only a single
NSOperationQueue
exists in your process
Couldn't you swizzle +[NSOperationQueue alloc] to return a
singleton? Sure it's a hack, but a simple one that can be #ifdefed
out for post Leopard builds. And would fix the problem for now if
you've already architected a project around operation queues.
Keith
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden