On Thu, Sep 3, 2009 at 2:49 PM, David Leimbach <[email protected]> wrote:
> > > On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach <[email protected]> wrote: > >> >> >> On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom <[email protected]>wrote: >> >>> On Thu Sep 3 17:09:01 EDT 2009, [email protected] 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 >>> >>> >> >
