On Fri, Sep 4, 2009 at 4:56 PM, David Leimbach<[email protected]> wrote: > > > On Fri, Sep 4, 2009 at 7:20 AM, erik quanstrom <[email protected]> > 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. meanwhile >> 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. if 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. And 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 > The advantage of the higher > level languages that were designed with concurrency in the language, is that > 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 that I > don't think are true about them. For example, claiming that blocks require > more locking is evidently false if you look at example code that's been > provided. DispatchLife, for example, includes contextual data pointing to > neighboring cells, and because of the serial nature of the queues involved, > 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 them > could be running at once. So if you code it up incorrectly, you sure could > have to do some locking. But 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 state. > And that is exactly why Apple bothered to do all of this. If not, they'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 work > with Grand Central Dispatch, I've not been provided a lot of options at the > moment to do anything else. > Dave >> >> - erik >> > >
