2009/9/10 Christopher Wright <[email protected]>: > My current experience is that QuickTime issues have not been solved. Yes, but we face them already anyway (and not without pain). The memory leak the note talks about, however, was more subtle, and has taken a lot of jumps around to overcome: that's something I'd love to see solved...
> I'm not sure if dispatch groups keep threads around, or if you have to keep >the > queue "full" (always busy, never idle) to keep the thread around. That's what we have to do know... threads kept idle to ensure that calls to QCRenderers happen on the right one... > That said, if you've already worked around the threading issues, and already > have a successful multithreaded implementation, I'm not sure what benefits > you'll get from GCD (other than automatic threadpool management, which is > pleasant but not a show-stopper). Not for now, sure... but evolving the software from a cleaner base is always tempting! And, if locking could be reduced that way, that's also a good thing, of course. 2009/9/11 Steve Christensen <[email protected]>: > So if you do elect to move away from straight threads, using NSOperation > might be a better way to do it unless you're willing to require 10.6 or > later for your app's users. Well, skimming through docs it seems that the way NSOperation ( & -Queue) works isn't exactly the same, many things have been added in 10.6 to make difficult to maintain backward compatibility if you want to use them in full (e.g. +mainQueue), and Dispatch Queues seem more flexible anyway (again, not examined the thing in depth yet, so I could be way off the mark here). Anyway, I guess I'll have to get myself the time to explore and find out... Thanks to Chris and Steve for taking the time to help me out! Cheers Paolo _______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
