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