On Thu, Sep 3, 2009 at 2:45 PM, David Leimbach <leim...@gmail.com> wrote:
> > > On Thu, Sep 3, 2009 at 2:35 PM, erik quanstrom <quans...@quanstro.net>wrote: > >> On Thu Sep 3 17:09:01 EDT 2009, r...@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 > Dave > > >> - erik >> >> >
