Sparc64 support

[Jordan Hubbard]

> On Aug 9, 2015, at 4:26 PM, Bill Sorenson <instructionset at gmail.com> wrote:
> 
> Forgive my ignorance though but I am curious as to the benefit of having
> libdispatch in base vs being a ports dependency. Is there much in the base
> system where it would be used? 

Well, it’s one of those libraries like libc and libpthreads - lots of things start to depend on such foundation technologies pretty quickly.  Libdispatch, for example, is depended on by Libnotify, which is key to distributed notifications on the system.  Various things in Libc want to post notifications when various key system resources change, in turn, so they depend on Libnotify.  Libdispatch itself, when done “all the way”, requires some kernel primitives (pthread_workqueue) to be even more efficient, though it can make do without.  It’s easier (and far less difficult to unravel dependencies) if you just think of these libraries as all part of a single gestalt.

That is why OS X has Libsystem - an umbrella framework which contains the common object runtime (retain / release / etc), the crypto routines, libdispatch, libnotify, XPC, etc.  Every executable “below and including the GUI apps” just depends on libSystem, which gives it a very rich runtime and the opportunities for additional layering.  Things like libdispatch and asl can use the same retain/release functions as the ObjectiveC runtime uses, for example, and you see this expressed up through their own APIs with calls like dispatch_retain() and asl_release() (and foo_object_t’s that support those semantics).

All of this “bedrock” is an integral part of any environment where the multi-threaded / memory managed object programming paradigm is essentially baked in to the fundamentals of the system and developers aren't constantly forced to ask themselves “Is this call thread safe?  Do I need to put my own locks around it?”

So yeah, you could put it into ports, but then you wouldn’t really have a common runtime on which to build higher layers, you’d just have a derivative platform again because anyone wanting to build those higher level things (and I can certainly elaborate on that if desired) needs to essentially build their own base out of base + ports.

Which is not to say that I think everything needs to be in base by any stretch.  Not arguing for emacs.  Not arguing for python (though I know that one comes up periodically).  Just arguing for the basic (2) and (3) level APIs to be extended a bit further so that really basic things like leveraging multi-core CPUs better, having more asynchronous interfaces, and having the system support notifications work.

- Jordan