Re: [9fans] "Blocks" in C

[David Leimbach <leimy2k@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3948 bytes --]

On Sun, Sep 6, 2009 at 3:35 PM, Uriel <uriel99@gmail.com> wrote:

> 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
>
> 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
> >>
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 5347 bytes --]