macOS How dynamic are Grand Central's "blocks"

[haravikk]

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!

 

[lee1210]

Even though the release is close, i don't think anyone that could answer this is allowed to until snow leopard is released.

-Lee

 

[haravikk]

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.

 

[Catfish_Man]

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.

 

[haravikk]

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

 

[Catfish_Man]

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

 

[Cinder6]

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?

 

[Catfish_Man]

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.