[libdispatch-dev] lib dispatch worker threads may loop depending on compiler optimization

[Joakim Johansson]

On 12 sep 2011, at 21:57, Jordan K. Hubbard wrote:

> Seeing as how gcc (outside of Apple) doesn't even support blocks, which I think we all agree are somewhat fundamental to GCD's ease-of-use, is there any real benefit to trying to grapple with gcc build issues in any case?  I have a hard time seeing the point of creating a build of libdispatch which only supports the _f() variants, in other words, and if the user is already essentially forced to use clang in order to truly benefit from libdispatch, then why not make the bootstrapping of clang on each given target platform a prerequisite?  (I googled for "clang for windows" and got a fair number of hits, btw, though I don't know how fully baked that port is yet).   Just a thought!
> 

I definitely agree that blocks are very nice (as is clang, which I hope that we will be able to use pending ability to build our C++ code, which was still lacking last time we tested). 

Even though we use clang to ensure that the full feature set of GCD is available on Solaris, we are currently actually using just such a subset which only supports the _f() variants and are finding it very useful indeed ;-) (for toolchain reasons, we are building the final cut with gcc) 

I think it would be a pity to drop this capability - at least in the short term - as clang matures further, that might well change going forward…

Given what has been discussed so far, it seems like reasonable next steps would be:

a) A short term workaround in GCD for the broken GCC intrinsics 
b) Pushing for fixing those broken intrinsics in GCC (it seems like a fairly dangerous bug for all code using the intrinsics)

Just $0.02

Cheers,

Joakim