From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <3e1162e60909020807t3164e42fvee3b6e5e4671743b@mail.gmail.com> References: <09650C1A-A4C8-4030-81D6-9AC8913970A2@kix.in> <3e1162e60909020807t3164e42fvee3b6e5e4671743b@mail.gmail.com> Date: Thu, 3 Sep 2009 17:32:56 +0200 Message-ID: <5d375e920909030832i17c62bc7mbb1afc55708e059a@mail.gmail.com> From: Uriel To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] "Blocks" in C Topicbox-Message-UUID: 616194f2-ead5-11e9-9d60-3106f5b1d025 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 wrote: > Has anyone actually looked at the spec or is this just armchair philosoph= y? > I've actually looked at these, and used em a little bit. =C2=A0They're no= t at all > as bad as I once thought they could be, and the reason they're there is t= o > work with a concurrency framework onto which blocks can be scheduled to r= un > 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? =C2=A0You bet! =C2=A0Imagine many concurrently running blocks p= laying with > shared global pointers... Luckily the serial queues are able to prevent t= hat > exact thing from happening. :-) > Does it make the code easier to read? =C2=A0So far my answer is no, not a= t all. > > Does it succeed in the goal of making it possible to do lockless programm= ing > of concurrent applications? =C2=A0Yes, there's several rather interesting > examples showing the concurrent computation of all the cells in Conway's > Life for example. =C2=A0I'd say this beats the snot out of coding with pt= hreads. > 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 libdispatc= h > 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 Cent= ral > Dispatch". > Dave > > On Wed, Sep 2, 2009 at 4:40 AM, Eris Discordia > 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 >> 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 elegan= t >>> and might be useful in cases where you want map/reduce like functionali= ty >>> in C. >>> >>> How much effort would it be to support a feature similar to blocks in 8= c >>> (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 >>> >> >> >> >> >> > >