From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5d375e920909061535u6d0180c8o5032c0afea1acf23@mail.gmail.com> References: <3e1162e60909031213k5209f296vb0a77ff858e45496@mail.gmail.com> <580135a14ad078bb8223e7c448a5fa2b@quanstro.net> <3e1162e60909031250v2914ab29s6e43e371f896712b@mail.gmail.com> <5d375e920909061535u6d0180c8o5032c0afea1acf23@mail.gmail.com> Date: Sun, 6 Sep 2009 17:41:34 -0700 Message-ID: <3e1162e60909061741y6aac08a9ufc8ae0a139310de0@mail.gmail.com> From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd23c28a37eed0472f21c9f Subject: Re: [9fans] "Blocks" in C Topicbox-Message-UUID: 67335af0-ead5-11e9-9d60-3106f5b1d025 --000e0cd23c28a37eed0472f21c9f Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 6, 2009 at 3:35 PM, Uriel wrote: > On Thu, Sep 3, 2009 at 9:50 PM, David Leimbach wrote: > > > > > > On Thu, Sep 3, 2009 at 12:36 PM, erik quanstrom > > 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 > > What do pthreads have to do with anything? Ever heard of libthread, > libtask and rfork? I guess not, Apple certainly hasn't, and they sure > are doing a great job at making their developers keep track of as much > Apple-induced crap as possible... > Guess what percentage of developers for Apple know anything at all about libthread, and libtask. I bet it's like me and maybe 4 or 5 other people. Also rfork was in the Mac OS X man pages early on, because the pages were essentially taken out of FreeBSD, which also had an rfork implementation. Pthreads, being a part of POSIX, are a lot more well known. I almost said understood, but I actually doubt the number of people who know what pthreads are know how to use them well. I doubt I could write much with them even today without looking over the man pages thoroughly as I've been spoiled by other ways. Since pthreads are mapped to Mac OS X's mach_threads, it seems to be a path of least resistance to try to implement stuff that works with them. And yeah, Apple does do a bit of "developer lock in" with their APIs. The only other place Cocoa stuff is even applicable is GNUStep, and even there it's a subset, though my understanding is the Cocoa bindings of GNU Emacs work on GNUStep equally well. I guess my point is, if you invent even the best new way to program something, or even a superior microprocessor or really anything at all, you have to overcome the big gorilla's out there, and convince them that your way is worth adopting. Also, keep in mind they needed to come up with something that worked with Objective-C, C++ and C equally well. Since they don't develop all that stuff in public, there's no telling what things they tried before settling in on blocks. > uriel > > > > seen whole OSes for x86 written in assembly. > > It all depends on how much crap you want to keep track of. > > Dave > > > >> > >> - erik > >> > > > > > > --000e0cd23c28a37eed0472f21c9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Sep 6, 2009 at 3:35 PM, Uriel <uriel99@gmail.com<= /a>> wrote:
On Thu, Sep 3, 2009 at 9:50 PM, David Lei= mbach<leimy2k@gmail.com> wro= te:
>
>
> 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 Leo= pard, in all their
>> > > > native
>> > > > apps to write cleaner, less manual-lock code. =A0At= least, that's the
>> > > > claim
>> > > > :-).
>> > >
>> > > could someone explain this to me? =A0i'm just missin= g how
>> > > naming a block of code could change its locking properti= es.
>> > >
>> > >
>> > The explanation is in the manual I linked to earlier in this = discussion.
>> > =A0If
>> > you want to see examples there's two I can think of avail= able for
>> > download.
>> > =A0One 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. =A0clearly<= br> >> i am a reprobate outside the apple reality distortion field.
>>
>
> Google doesn't have all the answers, I actually had to use Bing to= day, and
> it worked... anyway here's the link to DispatchLife.
> http://developer.apple.com/mac/library/samplecode/D= ispatchLife/
>
>>
>> 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 &quo= t;blog" about
> it, hopefully by Friday sometime (tomorrow).
> I don't agree that any of this stuff is strictly needed. =A0One ca= n plod along
> with pthreads and do it wrong all day. =A0One doesn't *need* C eit= her, I've

What do pthreads have to do with anything? Ever heard of libthr= ead,
libtask and rfork? I guess not, Apple certainly hasn't, and they sure are doing a great job at making their developers keep track of as much
Apple-induced crap as possible...

Guess= what percentage of developers for Apple know anything at all about libthre= ad, and libtask. =A0I bet it's like me and maybe 4 or 5 other people. = =A0

Also rfork was in the Mac OS X man pages early on, beca= use the pages were essentially taken out of FreeBSD, which also had an rfor= k implementation.

Pthreads, being a part of POSIX,= are a lot more well known. =A0I almost said understood, but I actually dou= bt the number of people who know what pthreads are know how to use them wel= l. =A0I doubt I could write much with them even today without looking over = the man pages thoroughly as I've been spoiled by other ways.

Since pthreads are mapped to Mac OS X's mach_thread= s, it seems to be a path of least resistance to try to implement stuff that= works with them.
=A0
And yeah, Apple does do a bit of = "developer lock in" with their APIs. =A0The only other place Coco= a stuff is even applicable is GNUStep, and even there it's a subset, th= ough my understanding is the Cocoa bindings of GNU Emacs work on GNUStep eq= ually well.

I guess my point is, if you invent even the best new wa= y to program something, or even a superior microprocessor or really anythin= g at all, you have to overcome the big gorilla's out there, and convinc= e them that your way is worth adopting. =A0

Also, keep in mind they needed to come up with somethin= g that worked with Objective-C, C++ and C equally well. =A0Since they don&#= 39;t develop all that stuff in public, there's no telling what things t= hey tried before settling in on blocks.


uriel


> seen whole OSes for x86 written in assembly.
> It all depends on how much crap you want to keep track of.
> Dave
>
>>
>> - erik
>>
>
>


--000e0cd23c28a37eed0472f21c9f--