I am working a bit on a Solaris port and will provide a few patches, looking forward to house-style comments etc. 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). It could help in initial portability to platforms without kqueue support. I'm sure there are some issues with disabling it that I'm not aware of, any pointers are appreciated. Joakim
On 11/06/2009 04:00 PM, Joakim Johansson wrote:
I am working a bit on a Solaris port and will provide a few patches, looking forward to house-style comments etc.
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 have a series (almost completed, need to resubmit the latest bits) to cut source.c into a kqueue part and a non-kqueue part. That would help you too. Paolo
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. That would have a chilling effect on application adoption since they could no longer assume what "API compatibility" meant on any given platform. 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. - Jordan
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
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
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
participants (3)
-
Joakim Johansson
-
Jordan K. Hubbard
-
Paolo Bonzini