[libdispatch-dev] Solaris portability
jocke at tbricks.com
Fri Nov 6 14:23:51 PST 2009
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
Well, it kind of reminds me of POSIX support over the years on many
> 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
More information about the libdispatch-dev