How dynamic are Grand Central's "blocks"

Discussion in 'Mac Programming' started by haravikk, Aug 24, 2009.

  1. haravikk macrumors 65816

    Joined:
    May 1, 2005
    #1
    I know I'm probably jumping the gun a bit in posting, but with Snow Leopard days away I figured I'd ask now to see what I can turn up.

    I'm currently working on developing a cross-platform application primarily in C++, however, I'm hoping to keep everything modular enough that I can still use OS/platform specific features to increase performance depending where I'm deploying it.

    Grand Central Despatch is one-such OS feature I'm very interested in, as it seems like it would provide a performance boost, either for the entire application, or for parts of it, as it should utilise processors more efficiently etc. However, what I'd like to know is; how dynamic are the "blocks" that GCD code is organised into?

    For example; say I have a library loaded at run-time, and wish to execute code which draws upon it within a GCD block, can this be done, or must all code executed in the blocks be available when they are compiled? Or the other way around, what if my GCD code was in a run-time library, and I wanted to pass objects to it to execute?

    My main concerns are that if it isn't very dynamic, and only properly works in a fully-compiled application, then it may restrict my options in using it. However, on the other hand if it can handle more complex cases, then it may mean a serialisation step of some kind which could have performance implications over thread-management built into my application.

    I'm hoping it works just by holding references to things within an application's memory, and is more of a way to execute app code using "on-loan" threads. But I'm interested how well it can actually work, and if there are any constraints on coding it.

    If anyone has an experience of this, or believes they know the answer then it'd be great to know! As I say, I intend to keep things as modular as possible, but the more I know ahead of time, the better I can plan for writing a GCD component for my app running on Snow Leopard.

    Thanks!
     
  2. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #2
    Even though the release is close, i don't think anyone that could answer this is allowed to until snow leopard is released.

    -Lee
     
  3. haravikk thread starter macrumors 65816

    Joined:
    May 1, 2005
    #3
    I know, but I'm hoping maybe the information that has been released (there are developer briefs and things available) may provide some insight I may have missed. I'm re-reading them now.
     
  4. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #4
    Blocks are conceptually similar to heap-allocated* structs that can be called, and carry most of the same behaviors in terms of how you can move them around. You can absolutely pass them into library calls, or get them back from library calls, or have libraries call your methods with them as arguments.

    http://www.mikeash.com/?page=pyblog/friday-qa-2008-12-26.html and http://www.mikeash.com/?page=pyblog/friday-qa-2009-08-14-practical-blocks.html have great information on the topic. The second also has a link to a compiler and library for using them on Leopard, so you can try them now. That doesn't include GCD of course, but it should let you get a feel for how blocks work.


    *optionally.
     
  5. haravikk thread starter macrumors 65816

    Joined:
    May 1, 2005
    #5
    Ah, thanks very much for that information! So if I understand it right, a block is like an inline class in Java? In Java the most common example is using inline Runnable classes to throw context-specific tasks into thread-pools, which I think is exactly what blocks are intended for too, but a bit more loosely.

    Hmm, in that case I think there shouldn't be any problems for me at least, except that I'll need to keep myself from over-using them :)
     
  6. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #6
    The main difference I see from Java is the stack capturing semantics (i.e. what makes them closures, rather than just anonymous function objects). Sounds like you've got the right idea though :)
     
  7. Cinder6 macrumors 6502

    Cinder6

    Joined:
    Jul 9, 2009
    #7
    Looks like this is anonymous functions, while Java's syntax allows for anonymous classes.

    I hadn't realized this would be an actual language addition; I'd expected APIs. Since it is a language feature, does it bump up the version number for Objective-C at all?
     
  8. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #8
    ObjC's versioning is insane anyway. 10.3 added language features without bumping the version, 10.5 bumped the version once but actually introduced two versions (ObjC2 and "real" ObjC2 with the new runtime and ABI). So, it's unclear what, if anything, the version number means.
     

Share This Page