Date: Sun, 09 Aug 2015 18:13:44 -0700 From: Jordan Hubbard <jordanhubbard@me.com> To: Bill Sorenson <instructionset@gmail.com> Cc: freebsd-hackers@freebsd.org, Kevin Bowling <kevin.bowling@kev009.com>, "K. Macy" <kmacy@freebsd.org> Subject: Re: Sparc64 support Message-ID: <51EEBC6E-5D85-439D-874D-D223EE045515@me.com> In-Reply-To: <CACcTwYktQRTqVSr7PRr5huwbVXVu6oCy26TKiAxzf2NiGAcocA@mail.gmail.com> References: <CACcTwYmS1c5uoO-WiJQDwgqYAevX7WZ7ZrP297hnOu7cNET3CA@mail.gmail.com> <mq3sg1$bno$1@ger.gmane.org> <CACcTwYnU=E-6sV3yLh3yKUSPZOg7967XV5ToXoSVPuNfOjF7hQ@mail.gmail.com> <CAHM0Q_NEYWxpHCwEdytfY6i9%2BRO2BebezzmenfQ_1c4u7zGrgg@mail.gmail.com> <CACcTwY=DcUREt5nJWo_eJfrB=3sQXBaS6nc%2B07fpZhxARD0zTQ@mail.gmail.com> <20150809215403.GC20238@server.rulingia.com> <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> <CACcTwYktQRTqVSr7PRr5huwbVXVu6oCy26TKiAxzf2NiGAcocA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Aug 9, 2015, at 4:26 PM, Bill Sorenson <instructionset@gmail.com> = wrote: >=20 > 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?=20 Well, it=E2=80=99s 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 =E2=80=9Call the way=E2=80=9D, requires some kernel primitives = (pthread_workqueue) to be even more efficient, though it can make do = without. It=E2=80=99s 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 =E2=80=9Cbelow and = including the GUI apps=E2=80=9D 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=E2=80=99s that support those = semantics). All of this =E2=80=9Cbedrock=E2=80=9D 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 =E2=80=9CIs this = call thread safe? Do I need to put my own locks around it?=E2=80=9D So yeah, you could put it into ports, but then you wouldn=E2=80=99t = really have a common runtime on which to build higher layers, you=E2=80=99= 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51EEBC6E-5D85-439D-874D-D223EE045515>