Date: Fri, 4 Apr 2014 13:33:34 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Jordan Hubbard <jkh@ixsystems.com> 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: <2E0EC8CB-B3EE-4DB8-A33D-58FD2107F14D@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
On 4 Apr 2014, at 13:23, Jordan Hubbard <jkh@ixsystems.com> 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 = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E0EC8CB-B3EE-4DB8-A33D-58FD2107F14D>