On 4 Apr 2014, at 13:23, Jordan Hubbard <j...@ixsystems.com> wrote: > On Apr 4, 2014, at 4:59 PM, David Chisnall <thera...@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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
