[libdispatch-dev] Solaris portability

[Jordan K. Hubbard]

On Nov 6, 2009, at 2:23 PM, Joakim Johansson wrote:

> On 6 nov 2009, at 22.44, Jordan K. Hubbard wrote:
>> On Nov 6, 2009, at 7:00 AM, Joakim Johansson wrote:
>> 
>>> One thought I played with, was to build libdispatch without support for event sources (except perhaps for timers), would that be something that would seem useful to others on the list (it would be analogous to disabling the support for blocks on platforms not supporting it).
>> 
>> I can see it being "sort of useful" to separate out the support of sources from the rest of the dispatch machinery on one hand, but on the other hand I can also see how this would lead to a rather neutered libdispatch and also make it less than clear just what the "official grand central dispatch API" looked like since different platforms were choosing to support different subsets.
> 
> I think the major argument for having such a subset, is that it would be more readily portable to a wider range of platforms (as kqueue/blocks are arguably the most platform-specific parts of libdispatch) - it would be an already useful drop-in for the major parts of libdispatch into existing applications that may already have another event mechanism in place, as a first step for adoption of the framework to get one's feet wet.

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 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. :-)

> 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.

- Jordan