On Thu, Sep 3, 2009 at 9:50 PM, David Leimbach<
leimy2k@gmail.com> wrote:
>
>
> On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom <
quanstro@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