From owner-svn-src-all@FreeBSD.ORG Fri Apr 4 12:31:38 2014 Return-Path: Delivered-To: svn-src-all@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 B29B6EE for ; Fri, 4 Apr 2014 12:31:38 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8944B8D3 for ; Fri, 4 Apr 2014 12:31:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s34CVc7b097482 for ; Fri, 4 Apr 2014 12:31:38 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s34CVcFk097479 for svn-src-all@freebsd.org; Fri, 4 Apr 2014 12:31:38 GMT (envelope-from bdrewery) Received: (qmail 99957 invoked from network); 4 Apr 2014 07:31:33 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 4 Apr 2014 07:31:33 -0500 Message-ID: <533EA61F.7030300@FreeBSD.org> Date: Fri, 04 Apr 2014 07:31:27 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jordan Hubbard , David Chisnall Subject: Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> In-Reply-To: <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> X-Enigmail-Version: 1.6 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SQAM8aBUqO9vfUmFSwwxErIQn4hx4FUKt" Cc: svn-src-head@freebsd.org, Baptiste Daroussin , src-committers@freebsd.org, svn-src-all@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 12:31:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SQAM8aBUqO9vfUmFSwwxErIQn4hx4FUKt Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/4/2014 7:23 AM, 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 i= s an in-tree consumer, but it's in ports and there's nothing stopping por= ts depending on it if they want to use it... >=20 > I certainly get and even generally agree with that point of view. It s= eems like putting the cart before the horse to bring in any technology be= fore there is a use case demanding said technology, right? >=20 > Right. However, I think there are also occasional exceptions to that r= ule. The strlcpy() / strlcat() / =85 family of functions, for example. = Until they existed (outside of OpenBSD), nobody really used them pervasiv= ely enough to achieve their intended purpose (death to buffer overflows i= n string handling) and it took bringing them in and essentially saying =93= see? there! use those now please!=94 for adoption and conversion of exi= sting string handling code to eventually, over the course of years, becom= e second nature. >=20 > I think libdispatch is in a very similar category, and you=92ll just ha= ve to trust me when I say that I=92ve had the benefit of watching multipl= e years worth of slow adoption work its magic there, too. Without libdis= patch, you just use pthreads whenever you need to do something in the bac= kground. Without libdispatch, you don=92t write code (in libraries or ap= plications) which assumes any sort of run loop at all because, well, ther= e 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 idio= m than a library. Without them, you simply write an entirely different s= tyle of synchronous, multi-threaded code with mutex locks and pthread joi= n and cancellation points, yada yada yada. Once libdispatch and blocks a= re part of the runtime, you slowly leave the old style stuff behind becau= se it=92s limited, painful and just nowhere near as sophisticated. To pa= raphrase 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 And= roid. 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 eve= r 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 her= e. What=92s worse, I also don=92t think anyone in *BSD-land is writing c= ode that=92s particularly event-aware (the lack of system-wide notificati= ons kind of speaks to that) largely *because* it=92s a PITA to do that wi= thout a runloop or handy glue code which makes it trivial, the alternativ= e being to use a background thread that tries to coordinate said events w= ith the foreground and that=92s just icky. The end-result of this is th= at an entire somewhat more modern style of programming, where things are = more dynamic in the face of things changing on the system, simply doesn=92= t happen at the OS level and that=92s a shame, because the OS *is* a dyna= mic environment, particularly in the mobile space. >=20 > I guess what I=92m advocating is nothing less than a leap of faith? >=20 > - Jordan >=20 Respectfully, as a developer, why would I want to use libdispatch and not libevent? Libevent looks far more portable. When I bring up the libdispatch page, I get no sense that picking it for my project makes sense. I'm not even clear what it is from looking at the page. When I pull up libevent's page, I get a much different picture right away, "Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX select(2), Windows select(), poll(2), and epoll(4)." --=20 Regards, Bryan Drewery --SQAM8aBUqO9vfUmFSwwxErIQn4hx4FUKt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTPqYfAAoJEDXXcbtuRpfPCeQH/RMWX58fLhbVXN3TNrOxWHCR CrDKDVAug0osSYdGpUAvJuBtA3wcp8/MhH1BK37Q9Jjz8segrto2baULH4ZBOrFY uvQKjADJ9UNt27H/lruvrFlvnqRW9zTeI53m0dmcq4sRT0rFP+rLIEU7wgwUDKaL eYsTmX+cVHQVoo54SuamKKFqtBAPGrag1L0KZc2ZGdYq3aYWpnuCbx9+B+2/c0X5 5GqWsv7fsS3BqRgqDrzdTAumydk6Bmk4KFu5IIBADlQ4ZrXgg8zIpvyRElvFn+pf 2cl7IS0EmxqI1yDyikx4WqTzxOPl5SH/T0F/gXvL74jUi+Yp/Jr+ugcCSWLsNBE= =OOEn -----END PGP SIGNATURE----- --SQAM8aBUqO9vfUmFSwwxErIQn4hx4FUKt--