From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <09650C1A-A4C8-4030-81D6-9AC8913970A2@kix.in> Date: Wed, 2 Sep 2009 08:07:48 -0700 Message-ID: <3e1162e60909020807t3164e42fvee3b6e5e4671743b@mail.gmail.com> From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd4c78061b1ef047299a1be Subject: Re: [9fans] "Blocks" in C Topicbox-Message-UUID: 5ef482d8-ead5-11e9-9d60-3106f5b1d025 --000e0cd4c78061b1ef047299a1be Content-Type: text/plain; charset=ISO-8859-1 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 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 < > anant@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 >> >> > > > > > --000e0cd4c78061b1ef047299a1be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Has anyone actually looked at the spec or is this just armchair philosophy?= =A0

I've actually looked at these, and used em a lit= tle bit. =A0They'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 on= to which blocks can be scheduled to run on various queues, to do concurrent= programming. =A0

If you're running Snow Leopard, they're being u= sed 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? =A0You bet! =A0Imagine many concurrently running blocks playing = with shared global pointers... Luckily the serial queues are able to preven= t that exact thing from happening. :-)

Does it make the code easier to read? =A0So far my answ= er is no, not at all.

Does it succeed in the goal of maki= ng it possible to do lockless programming of concurrent applications? =A0Ye= s, there's several rather interesting examples showing the concurrent c= omputation of all the cells in Conway's Life for example. =A0I'd sa= y this beats the snot out of coding with pthreads.

However, if I want real concurrency programming, I woul= d NEVER use C over Erlang or Haskell by choice (or Limbo if it's availa= ble). =A0

Blocks themselves are really not terribl= y useful, you need the libdispatch library to make the real value in them c= ome out, which does all the queue management by talking to the subsystem of= Snow Leopard called "Grand Central Dispatch". =A0

Dave

On Wed, Sep 2, 2= 009 at 4:40 AM, Eris Discordia <eris.discordia@gmail.com> wrote:
Perl people love closures. It's one of their common programming techniq= ues. 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 h= ow the binary looks but allows programmers to pepper source with brain-teas= ers (now, what does _that_ evaluate to?). Not good at all.


--On Wednesday, September 02, 2009 10:04 +0200 Anant Narayanan <anant@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<= br> 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-o= s-x-10-6.ars/10







--000e0cd4c78061b1ef047299a1be--