[libdispatch-dev] Solaris portability

[Joakim Johansson]

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.

Acceptance of such a subset might also increase the likelihood of more  
commits by people who want to plug "that final gap" as well.

That being said, I do acknowledge and agree that having a clear view  
of what is really included in an API is a good thing, but having  
optional subsystems of an API is fairly common also (cf. POSIX,  
CoreFoundation, mDNSResponder, ...), sometimes it's just a necessity  
for progress. As long as the long term implementations converges to a  
common full feature set, it may be acceptable - thus my query on  
whether anyone else saw this as a useful thing (who unfortunately  
lacked a question mark at the end).

> 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 would far prefer to see an OS port delayed and then come out with  
> support for the full API, including blocks, than see support arrive  
> sooner but piecemeal.

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...) - I do appreciate the standpoint though (and indeed,  
the ambition is definitely to get the event sources working as well,  
on Solaris I'm investigating using the Event Completion Framework if  
possible - http://developers.sun.com/solaris/articles/event_completion.html 
  ).

Cheers,

Joakim