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? - Jordan _______________________________________________ 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"
