From owner-svn-src-head@FreeBSD.ORG Fri Apr 4 12:33:43 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEA482BD; Fri, 4 Apr 2014 12:33:43 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "theravensnest.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D19B8F2; Fri, 4 Apr 2014 12:33:43 +0000 (UTC) Received: from [192.168.0.100] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s34CXckJ072814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Apr 2014 12:33:40 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib From: David Chisnall In-Reply-To: <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> Date: Fri, 4 Apr 2014 13:33:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E0EC8CB-B3EE-4DB8-A33D-58FD2107F14D@FreeBSD.org> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1874) Cc: svn-src-head@freebsd.org, Baptiste Daroussin , src-committers@freebsd.org, svn-src-all@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:33:44 -0000 On 4 Apr 2014, at 13:23, Jordan Hubbard wrote: > On Apr 4, 2014, at 4:59 PM, David Chisnall = wrote: >=20 >> I believe that libdispatch most likely won't be imported until there = is an in-tree consumer, but it's in ports and there's nothing stopping = ports depending on it if they want to use it... >=20 > I certainly get and even generally agree with that point of view. It = seems like putting the cart before the horse to bring in any technology = before there is a use case demanding said technology, right? >=20 > Right. However, I think there are also occasional exceptions to that = rule. The strlcpy() / strlcat() / =85 family of functions, for example. = Until they existed (outside of OpenBSD), nobody really used them = pervasively enough to achieve their intended purpose (death to buffer = overflows in string handling) and it took bringing them in and = essentially saying =93see? there! use those now please!=94 for = adoption and conversion of existing string handling code to eventually, = over the course of years, become second nature. >=20 > I think libdispatch is in a very similar category, and you=92ll just = have to trust me when I say that I=92ve had the benefit of watching = multiple years worth of slow adoption work its magic there, too. = Without libdispatch, you just use pthreads whenever you need to do = something in the background. Without libdispatch, you don=92t write = code (in libraries or applications) which assumes any sort of run loop = at all because, well, there isn=92t one. Without libdispatch, you still = write careful and limited signal handling functions because there=92s no = signal trampoline to save your butt if you try to do to much in a signal = handler. I could go on at length! >=20 > Libdispatch (with blocks) is, in short, more akin to a programming = idiom than a library. Without them, you simply write an entirely = different style of synchronous, multi-threaded code with mutex locks and = pthread join and cancellation points, yada yada yada. Once libdispatch = and blocks are part of the runtime, you slowly leave the old style stuff = behind because it=92s limited, painful and just nowhere near as = sophisticated. To paraphrase something I heard from more than a few = dozen software engineers over the years: =93Libdispatch is the = multithreaded programming paradigm I never knew I always wanted.=94 >=20 > There=92s a reason it=92s been ported to everything from Windows to = Android. It=92s hard to go back, once you have made the switch. >=20 > Back to my point, however: I don=92t think FreeBSD programmers are = ever going to embrace an idiomatic change of that nature (and it=92s = pretty significant) until it is part of base, so there=92s really a = deadlock here. What=92s worse, I also don=92t think anyone in *BSD-land = is writing code that=92s particularly event-aware (the lack of = system-wide notifications kind of speaks to that) largely *because* it=92s= a PITA to do that without a runloop or handy glue code which makes it = trivial, the alternative being to use a background thread that tries to = coordinate said events with the foreground and that=92s just icky. The = end-result of this is that an entire somewhat more modern style of = programming, where things are more dynamic in the face of things = changing on the system, simply doesn=92t happen at the OS level and = that=92s a shame, because the OS *is* a dynamic environment, = particularly in the mobile space. >=20 > I guess what I=92m advocating is nothing less than a leap of faith? I would certainly be in favour of importing it. The package seems to be = on every FreeBSD machine that I use, so I've become accustomed to having = it there and just work. =20 The slight problem, however, is that we would still like to be able to = build the base system with a more or less standard C compiler. Blocks = are in clang and are slowly making their way into commercial compilers, = but the only two versions of gcc that support them are the ones shipped = by Apple and FreeBSD. =20 In the commit that started this thread, I was careful to ensure that the = code that consumes blocks works correctly with a C compiler that doesn't = support blocks. Unfortunately, libdispatch just does #ifdef __BLOCKS__ = all over the place, and so you get a binary with a different interface. =20= This gets worse when we start to actually use blocks in the base system. = Hopefully, gcc upstream will gain blocks support soon (apparently = someone at Mentor Embedded is working on it?), and then we can start to = more seriously consider them for things in the base system. David