From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <3e1162e60909031449o12f9a0c2k1474afdecc9156cb@mail.gmail.com> References: <1252012116.16936.5128.camel@work.SFBay.Sun.COM> <9ec1e4e59a6d111588ad2a506f1bb5e2@quanstro.net> <3e1162e60909031445h7b09d381ya0c220d5ca1b40bb@mail.gmail.com> <3e1162e60909031449o12f9a0c2k1474afdecc9156cb@mail.gmail.com> Date: Thu, 3 Sep 2009 14:51:12 -0700 Message-ID: <3e1162e60909031451u1aa455a0n8efe271b6f7b439b@mail.gmail.com> From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd4cc0ad38caf0472b36161 Subject: Re: [9fans] "Blocks" in C Topicbox-Message-UUID: 630908ee-ead5-11e9-9d60-3106f5b1d025 --000e0cd4cc0ad38caf0472b36161 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 3, 2009 at 2:49 PM, David Leimbach wrote: > > > On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach wrote: > >> >> >> On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom wrote: >> >>> On Thu Sep 3 17:09:01 EDT 2009, rvs@sun.com wrote: >>> > Anything can be done using regular C and threads. The trick here >>> > is to make everything *scalable* and *painless* enough so that >>> > mere mortals can start benefiting from parallelism in their code. >>> > >>> > The other trick here is to find a model that makes things *natural*, >>> and >>> > that means practically no explicit locking, less shared state, etc. >>> > >>> > The search for the model is meaningless unless it is used for >>> > solving *practical* challenges. In that respect, one of my >>> > favorite article is how implementation of a chess engine >>> > influenced Cilk framework (which almost has the notion of a "block") >>> > http://supertech.csail.mit.edu/papers/icca99.pdf >>> > >>> > Read it, I don't think we can be on the same page (and escape the >>> > armchair philosophy trap) unless we are talking about practical >>> > applications of the framework. >>> > >>> > Look at the chess example -- can the same be done with pure C? Sure! >>> > Did Cilk make it less painful? Absolutely! >>> >>> my question was, what's naming your function pointers >>> or not got to do with locking? i'm asking about the language >>> construct, not the library er i mean "framework" and maybe runtime >>> that goes with it. >>> >>> >> Maybe if you see the block implementation you wouldn't think it was merely >> naming a function pointer? >> >> http://clang.llvm.org/docs/BlockImplementation.txt >> >> > also > > { > int X; > call_a_block(^(int y) {print (X+y); }); > } > > The block has a snapshot of that stack variable "X". > > It really does work a bit more like a closure than a function pointer. > > Dave > Also this doc is the spec: http://clang.llvm.org/docs/BlockLanguageSpec.txt > > >> Dave >> >> >>> - erik >>> >>> >> > --000e0cd4cc0ad38caf0472b36161 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 3, 2009 at 2:49 PM, David Le= imbach <leimy2k@g= mail.com> wrote:


On Thu= , Sep 3, 2009 at 2:45 PM, David Leimbach <leimy2k@gmail.com>= wrote:


On Thu, Sep 3, 2009= at 2:35 PM, erik quanstrom <quanstro@quanstro.net> wrot= e:
On Thu Sep =A03 17:09:01 EDT 2009, rvs@sun.com wrote:
> Anything can be done using regular C and threads. The trick here
> is to make everything *scalable* and *painless* enough so that
> mere mortals can start benefiting from parallelism in their code.
>
> The other trick here is to find a model that makes things *natural*, a= nd
> that means practically no explicit locking, less shared state, etc. >
> The search for the model is meaningless unless it is used for
> solving *practical* challenges. In that respect, one of my
> favorite article is how implementation of a chess engine
> influenced Cilk framework (which almost has the notion of a "bloc= k")
> =A0 =A0http://supertech.csail.mit.edu/papers/icca99.pdf
>
> Read it, I don't think we can be on the same page (and escape the<= br> > armchair philosophy trap) unless we are talking about practical
> applications of the framework.
>
> Look at the chess example -- can the same be done with pure C? Sure! > Did Cilk make it less painful? Absolutely!

my question was, what's naming your function pointers
or not got to do with locking? =A0i'm asking about the language
construct, not the library er i mean "framework" and maybe runtim= e
that goes with it.


=
Maybe if you see the block implementation you wouldn't think it wa= s merely naming a function pointer?



also

{
=A0int X;
=A0call_a_block(^(int = y) {print (X+y); });
}

The block has a s= napshot of that stack variable "X". =A0

It really does work a bit more like a closure than a fu= nction pointer.

Dave
=
= =A0
Dave
=A0
- erik




--000e0cd4cc0ad38caf0472b36161--