svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib

[David Chisnall]

On 4 Apr 2014, at 13:23, Jordan Hubbard <jkh at ixsystems.com> wrote:

> On Apr 4, 2014, at 4:59 PM, David Chisnall <theraven at 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() / … 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 “see?  there!  use those now please!” 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’ll just have to trust me when I say that I’ve 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’t write code (in libraries or applications) which assumes any sort of run loop at all because, well, there isn’t one.  Without libdispatch, you still write careful and limited signal handling functions because there’s 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’s limited, painful and just nowhere near as sophisticated.  To paraphrase something I heard from more than a few dozen software engineers over the years:  “Libdispatch is the multithreaded programming paradigm I never knew I always wanted.”
> 
> There’s a reason it’s been ported to everything from Windows to Android.  It’s hard to go back, once you have made the switch.
> 
> Back to my point, however:  I don’t think FreeBSD programmers are ever going to embrace an idiomatic change of that nature (and it’s pretty significant) until it is part of base, so there’s really a deadlock here.  What’s worse, I also don’t think anyone in *BSD-land is writing code that’s particularly event-aware (the lack of system-wide notifications kind of speaks to that) largely *because* it’s 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’s 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’t happen at the OS level and that’s a shame, because the OS *is* a dynamic environment, particularly in the mobile space.
> 
> I guess what I’m 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.  

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.  

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.  

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