So libthread must be a figment of 9fan's imagination... Of course, for Apple (or anyone else) to learn from Plan 9 would be impossible, so instead they had to add a new 'feature' to C.
uriel On Wed, Sep 2, 2009 at 5:07 PM, David Leimbach<leim...@gmail.com> wrote: > Has anyone actually looked at the spec or is this just armchair philosophy? > I've actually looked at these, and used em a little bit. They're not at all > as bad as I once thought they could be, and the reason they're there is to > work with a concurrency framework onto which blocks can be scheduled to run > on various queues, to do concurrent programming. > If you're running Snow Leopard, they're being used all over the place for > thread management. > Here's my objective and actually informed review: > Can something go horribly wrong with these blocks if you don't use them > properly? You bet! Imagine many concurrently running blocks playing with > shared global pointers... Luckily the serial queues are able to prevent that > exact thing from happening. :-) > Does it make the code easier to read? So far my answer is no, not at all. > > Does it succeed in the goal of making it possible to do lockless programming > of concurrent applications? Yes, there's several rather interesting > examples showing the concurrent computation of all the cells in Conway's > Life for example. I'd say this beats the snot out of coding with pthreads. > However, if I want real concurrency programming, I would NEVER use C over > Erlang or Haskell by choice (or Limbo if it's available). > Blocks themselves are really not terribly useful, you need the libdispatch > library to make the real value in them come out, which does all the queue > management by talking to the subsystem of Snow Leopard called "Grand Central > Dispatch". > Dave > > On Wed, Sep 2, 2009 at 4:40 AM, Eris Discordia <eris.discor...@gmail.com> > wrote: >> >> Perl people love closures. It's one of their common programming >> techniques. Closures in C? Way to screw its clarity and closeness to the >> real (or virtual) machine. And in the end closure or no closure doesn't >> change how the binary looks but allows programmers to pepper source with >> brain-teasers (now, what does _that_ evaluate to?). Not good at all. >> >> --On Wednesday, September 02, 2009 10:04 +0200 Anant Narayanan >> <an...@kix.in> wrote: >> >>> Mac OS 10.6 introduced a new C compiler frontend (clang), which added >>> support for "blocks" in C [1]. Blocks basically add closures and >>> anonymous functions to C (and it's derivatives). Full details with >>> examples are in the linked article. I think the feature is quite elegant >>> and might be useful in cases where you want map/reduce like functionality >>> in C. >>> >>> How much effort would it be to support a feature similar to blocks in 8c >>> (and family)? What are your thoughts on the idea in general? >>> >>> -- >>> Anant >>> >>> [1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10 >>> >> >> >> >> >> > >
