Date: Fri, 04 Apr 2014 07:31:27 -0500 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Jordan Hubbard <jkh@ixsystems.com>, David Chisnall <theraven@FreeBSD.org> Cc: svn-src-head@freebsd.org, Baptiste Daroussin <bapt@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib Message-ID: <533EA61F.7030300@FreeBSD.org> In-Reply-To: <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com> References: <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <F2A33EA8-14F2-4D62-9021-9023A1751E48@FreeBSD.org> <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <theraven@FreeBSD.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?533EA61F.7030300>