On 4/4/2014 7:23 AM, Jordan Hubbard 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? > > - Jordan >
Respectfully, as a developer, why would I want to use libdispatch and not libevent? Libevent looks far more portable. When I bring up the libdispatch page, I get no sense that picking it for my project makes sense. I'm not even clear what it is from looking at the page. When I pull up libevent's page, I get a much different picture right away, "Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX select(2), Windows select(), poll(2), and epoll(4)." -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature
