From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <3e1162e60909040756r3e114e84v82412406620d22cc@mail.gmail.com> References: <3e1162e60909040652y5504130dqc7bc737452193ad5@mail.gmail.com> <9fe2df93f80bf5bea9bf494f1436edf0@quanstro.net> <3e1162e60909040756r3e114e84v82412406620d22cc@mail.gmail.com> Date: Mon, 7 Sep 2009 01:03:17 +0200 Message-ID: <5d375e920909061603i428f54bfm97179b168f0af11d@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: 6720dd80-ead5-11e9-9d60-3106f5b1d025 On Fri, Sep 4, 2009 at 4:56 PM, David Leimbach wrote: > > > On Fri, Sep 4, 2009 at 7:20 AM, erik quanstrom > wrote: >> >> > I could be wrong, but I feel like you're not really interested in >> > entertaining that this idea could be useful, but more interested in >> > shooting >> > it down [...] >> >> remember, if a guy says to the king, hey you're fly's undone, >> we send that guy to the stockades for a week. =C2=A0meanwhile >> the king's fly remains undone. >> >> since the raison d'etre of blocks is ease of programming, >> i would think it would follow that it should be uniformly >> easier across the board. =C2=A0if there are big exceptions to this >> (like extra locking), i would think the feature would earn >> a fail. >> > > I am totally agreeing with you so far on all points you've just made. =C2= =A0And I > think that's why Apple is seeking feedback. Here is some feedback for Apple: Fire your whole software and programming division, they are making the GNU and Gnome crack monkeys look sane, competent and responsible. uriel >=C2=A0The advantage of the higher > level languages that were designed with concurrency in the language, is t= hat > you don't feel like you're twiddling the bits manually so much to express= an > algorithm. > >> >> i'm just noting that if blocks require locking as you mention, >> then this is inferior to calling a function through a pointer. > > Indeed. > >> >> unless you don't accept more locking is worse, it's hard to >> argue this point. > > My entire point is this will often allow you to get away with far less > locking, or at least, that's what the intention of all of this is. > >> >> you can accuse me of hating, that won't change how blocks >> work. > > > I'm not saying you are hating on blocks, I said I'm beginning to feel as = if > perhaps you're trying to find holes in it, but you keep saying things tha= t I > don't think are true about them. For example, claiming that blocks requir= e > more locking is evidently false if you look at example code that's been > provided. =C2=A0DispatchLife, for example, includes contextual data point= ing to > neighboring cells, and because of the serial nature of the queues involve= d, > it's impossible to have two threads updating the same shared data at once= . > The story is different if you take those same blocks, and have them > scheduled to run on the global concurrent queue, in which case many of th= em > could be running at once. =C2=A0So if you code it up incorrectly, you sur= e could > have to do some locking. =C2=A0But if you take advantage of the (too many= in my > opinion) abstractions provided that help to guarantee you will not need > locking, then you shouldn't need to do any explicit locking of shared sta= te. > And that is exactly why Apple bothered to do all of this. =C2=A0If not, t= hey're > totally wasting their time, because, as you've said, to create something > that would require more locking is a big lose. > >> >> > Deep down inside, I want people to stop trying to code stuff like this >> > in C >> > and try the massively scaled parallelism/concurrency stuff in other >> > languages better suited to the problem space. >> >> why would you use c then? > > Because if I wanted to write something for Mac OS X, and I needed it to w= ork > with Grand Central Dispatch, I've not been provided a lot of options at t= he > moment to do anything else. > Dave >> >> - erik >> > >