On 7 nov 2009, at 04.12, Jordan K. Hubbard wrote:

Well, let's see what Paolo's's patches for separating out the kqueue dependent bits look like first.  I could see a version of reality in which "core sources" (that is to say, not clearly OS-specific ones, like MacOSX's DISPATCH_SOURCE_TYPE_MACH_* sources) which weren't wired up underneath simply wouldn't fire, e.g. your "cross-platform GCD code" compiles just fine on a new dispatch-supporting platform, but some of the sources are stubbed out underneath.  You can register for such a source all day long, but you'll never have one fire.

That is really what I envisioned, I would definitely see significant value in that from a pragmatic viewpoint. Looking forward to see Paolo's patches.

That would have a chilling effect on application adoption since they could no longer assume what "API compatibility" meant on any given platform.

Well, it kind of reminds me of POSIX support over the years on many platforms... :-)

I'm not sure if you're trying to support my point or your point there. :-)

I guess you can take your pick really ;-)

It was just a little bit tongue-in-cheek after having done a few shims over the years, mostly for NeXTSTEP and early versions of Mac OS X :-)

As a sidenote, I'm really happy with the huge progress that was made the last few years on OS X in this area, it definitely makes life easier.


Fair enough, although blocks may not be possible if building with e.g. the Sun Studio compiler (which I hope we'll eventually being able to build with...)

Well, I can see how targeting the Sun Studio compiler might impose some additional pre-processing, yes.  The clang project, assuming you can build LLVM/clang reasonably well on Solaris (I haven't tried), provides a rewriter, for example, which just makes the blocks compiler runtime a (normal) library dependency.

Aha, that sounds extremely interesting, will definitely have a look at that and see if it builds (I really would like to have blocks available as a cross-platform feature)! 

Of course, after that, unfortunately the black rider of C++ comes into the picture (for us), which makes it troublesome until clang supports the language more extensively...

Joakim