macOS How dynamic are Grand Central's "blocks"

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!

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.

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