From owner-freebsd-hackers@freebsd.org Mon Aug 10 01:13:47 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD16B998223 for ; Mon, 10 Aug 2015 01:13:47 +0000 (UTC) (envelope-from jordanhubbard@me.com) Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtpout002.mac.com [17.158.232.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5E62D96; Mon, 10 Aug 2015 01:13:47 +0000 (UTC) (envelope-from jordanhubbard@me.com) Received: from [10.20.30.57] (75-101-82-48.static.sonic.net [75.101.82.48]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NSU007CBE2W6710@nk11p03mm-asmtp002.mac.com>; Mon, 10 Aug 2015 01:13:46 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-08-09_02:2015-08-07,2015-08-09,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1508100021 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Sparc64 support From: Jordan Hubbard In-reply-to: Date: Sun, 09 Aug 2015 18:13:44 -0700 Cc: freebsd-hackers@freebsd.org, Kevin Bowling , "K. Macy" Content-transfer-encoding: quoted-printable Message-id: <51EEBC6E-5D85-439D-874D-D223EE045515@me.com> References: <20150809215403.GC20238@server.rulingia.com> <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> To: Bill Sorenson X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 01:13:47 -0000 > On Aug 9, 2015, at 4:26 PM, Bill Sorenson = 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