Linked by Thom Holwerda on Tue 13th Oct 2009 18:24 UTC, submitted by Lazarus
FreeBSD Not too long ago, Apple open sourced its Grand Central Dispatch library, which aids in developing multithreaded code. It was suggested that it could be ported to other platforms, and the FreeBSD team has done exactly that. They have also done a lot of work related to getting GCD to work in a POSIX environment.
Thread beginning with comment 389073
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Neato
by zlynx on Tue 13th Oct 2009 21:35 UTC in reply to "RE[2]: Neato"
Member since:

Not completely different.

AFAIK, "blocks" is a bit of syntactic sugar that makes it much easier to write:

struct anon_func_1_state_s {
scope_var_a_type a;
scope_var_b_type b;
int c;
int d;

void anon_func_1(void *state)

const struct anon_func_1_state_s anon_func_1_state = {scope_var_a, scope_var_b, 3, 4};
dispatch_async_f(queue, &anon_func_1_state, &anon_func_1);

But behind the scenes a block is exactly the same as the above, and a heck of a lot easier to write.

Again, AFAIK.

Reply Parent Score: 3

RE[4]: Neato
by Mark Williamson on Wed 14th Oct 2009 02:45 in reply to "RE[3]: Neato"
Mark Williamson Member since:

Not completely different.

AFAIK, "blocks" is a bit of syntactic sugar that makes it much easier to write:

I thought that - and that seemed like an extension I'd be happy to have. But then I read something about the closure structure getting automatically copied to the heap if necessary, in certain circumstances. You can see you'd need to do this if you wanted to pass someone a closure to be called on completion, then return from the function you're currently running in.

The question is whether the C runtime is doing this or whether it's some kind of magic in GCD. If it's magic in GCD then I'm happy. If it's magic that's added to the C runtime then I'm not - C does not do heap memory allocations behind your back in basically any other context. so the addition of such would be highly disruptive. I'd really like clarification on how this blocks feature works!

Assuming it *is* just syntactic sugar then I would be all for it, I think that would be a fantastic feature for cutting down on code verbosity whilst still remaining close to the hardware.

Reply Parent Score: 3

RE[5]: Neato
by Lunix on Wed 14th Oct 2009 05:12 in reply to "RE[4]: Neato"
Lunix Member since:

Theres plenty of info here:

Aside from the closure structure, there's a second structure for __block variables (which are shared and mutable). There may also code generated for calling c++ copy constructors/destructors and Objective C retain/release-ing.

Blocks are never magically moved from the stack to the heap. There are two runtime function calls -- Block_copy(block) and Block_destroy(block) -- for managing block lifetime. (Objective C people can use [block copy] / [block release]).

If the block is stored on the stack, Block_copy will copy it to the heap (and return a pointer to the new heap block). Otherwise, it just increments a reference counter.

If you pass your block to a function that keeps it around for later, then it will get copied to the heap (if necessary). C is not doing anything behind your back, though.

Edited 2009-10-14 05:14 UTC

Reply Parent Score: 3