On Thu, Sep 3, 2009 at 4:50 PM, David Leimbach<leim...@gmail.com> wrote: > > > On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom <quans...@quanstro.net> > wrote: >> >> > > > Apple's using it all over the place in Snow Leopard, in all their >> > > > native >> > > > apps to write cleaner, less manual-lock code. At least, that's the >> > > > claim >> > > > :-). >> > > >> > > could someone explain this to me? i'm just missing how >> > > naming a block of code could change its locking properties. >> > > >> > > >> > The explanation is in the manual I linked to earlier in this discussion. >> > If >> > you want to see examples there's two I can think of available for >> > download. >> > One is called DispatchLife the other is DispatchFractal. >> > >> > I've looked at DispatchLife, and there's no explicit locking of state >> > for >> > every cell being concurrently update in Conway's game of life. >> >> i can't find DispatchLife after a few minutes of googling. >> i've read the manual, and it looks like csp to me. clearly >> i am a reprobate outside the apple reality distortion field. >> > > Google doesn't have all the answers, I actually had to use Bing today, and > it worked... anyway here's the link to DispatchLife. > http://developer.apple.com/mac/library/samplecode/DispatchLife/ > >> >> could you explain why this isn't csp and why this can't be done >> with regular c (that is why we need the concept of an >> unnamed function pointer) and the thread library? > > I'm actually planning to figure this stuff out a bit more and "blog" about > it, hopefully by Friday sometime (tomorrow). > I don't agree that any of this stuff is strictly needed. One can plod along > with pthreads and do it wrong all day. One doesn't *need* C either, I've > seen whole OSes for x86 written in assembly. > It all depends on how much crap you want to keep track of. > Dave >
or how much crap you want to dive into without noticing. iru