On Thu, Mar 18, 2010 at 12:05 PM, Jens Alfke <j...@mooseyard.com> wrote: > > On Mar 18, 2010, at 8:35 AM, Michael Ash wrote: > >> Cocoa keeps around a lot of thread-specific state. In addition to >> autorelease pools, you also have exception handlers, graphics >> contexts, and possibly others. > > Yup. I quickly ran into this in 2008 when experimenting with implementing > coroutines (which use the same ucontext stuff.) Lightweight > threads/coroutines can be very useful for highly scalable systems — that's > one reason there's a lot of hype about Erlang these days — but you can't > graft them on top of a runtime that doesn't know about them and already has > its own threading support. > > I haven't had a chance yet to use the Grand Central / dispatch-queue stuff > in 10.6, but I believe that it offers some similar functionality, like being > able to create huge numbers of concurrent operations without having each one > create a kernel thread.
GCD sort of kind of offers this. The big difference with GCD is that the individual jobs submitted to GCD can't be preempted, except by the normal rules of preemptive multithreading (GCD worker threads are just pthreads). If you load up GCD with enough jobs to keep your CPU busy, then submit one more job, that job has to wait until a running job completes before it gets a chance to run. You can get more granularity by dividing your work into smaller jobs, of course. Where GCD can really shine for tasks like the original poster mentioned is with dispatch sources. These allow you to, among other things, manage asynchronous I/O using callbacks in a way that's pretty easy to write and gives you good performance. You can basically just load up GCD with file descriptors to monitor, and it'll call you when data is available (or when space is available for writing). By using blocks, your code looks close to what it would look like with synchronous I/O, you don't have to use one kernel thread for each I/O source, and if you do intensive computations on multiple I/O sources, GCD will give you a multicore speedup pretty much for free. 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
