From owner-svn-src-head@FreeBSD.ORG Fri Apr 4 12:24:10 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FA83BC8; Fri, 4 Apr 2014 12:24:10 +0000 (UTC) Received: from mail.iXsystems.com (newknight.ixsystems.com [206.40.55.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B72847FE; Fri, 4 Apr 2014 12:24:09 +0000 (UTC) Received: from localhost (mail.ixsystems.com [10.2.55.1]) by mail.iXsystems.com (Postfix) with ESMTP id 3C06B735E8; Fri, 4 Apr 2014 05:24:09 -0700 (PDT) Received: from mail.iXsystems.com ([10.2.55.1]) by localhost (mail.ixsystems.com [10.2.55.1]) (maiad, port 10024) with ESMTP id 88788-08; Fri, 4 Apr 2014 05:24:09 -0700 (PDT) Received: from [192.168.3.175] (unknown [124.195.210.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.iXsystems.com (Postfix) with ESMTPSA id CCD3C735E2; Fri, 4 Apr 2014 05:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ixsystems.com; s=newknight0; t=1396614248; bh=VWy2a38d8raAOTaPSJm2ijZ+UPUpanJMPEiQl8Ifr3w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=wr5FMiHYTDsuqY3sYdmO56vb5TeKFudyXQ9E14D5KEzbdUM4x3EGWLM/c4ycw5gPJ Jj7K4grBtV0Y7mRickyNIwJ/SwmHJL1Dae6E8GLxipV6Lv/QnQZ3QpP/QVUOEquD3I kLl727z9KDpPv16y/XNi9mgYPZpJC5PjDvbcuwfI= 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: Jordan Hubbard In-Reply-To: Date: Fri, 4 Apr 2014 17:23:53 +0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> To: David Chisnall 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:24:10 -0000 On Apr 4, 2014, at 4:59 PM, David Chisnall wrote: > 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... 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? 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. 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! 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 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. 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. I guess what I=92m advocating is nothing less than a leap of faith? - Jordan