Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Apr 2014 17:23:53 +0500
From:      Jordan Hubbard <jkh@ixsystems.com>
To:        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:  <8D6AF193-A5A3-4A28-A230-97A543395ACA@ixsystems.com>
In-Reply-To: <F2A33EA8-14F2-4D62-9021-9023A1751E48@FreeBSD.org>
References:  <201404021607.s32G7mhw051355@svn.freebsd.org> <20140404115256.GA85137@ivaldir.etoilebsd.net> <F2A33EA8-14F2-4D62-9021-9023A1751E48@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 4, 2014, at 4:59 PM, David Chisnall <theraven@FreeBSD.org> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8D6AF193-A5A3-4A28-A230-97A543395ACA>