Apple's Grand Central Dispatch Ported To FreeBSD 205
bonch writes "Apple's Grand Central Dispatch, which was recently open sourced, has been ported to FreeBSD and is planned to be included by default in FreeBSD 8.1. Also known as libdispatch, the API allows the use of function-based callbacks but will also support blocks if built using FreeBSD's clang compiler package. There's already discussion of modifying BSD's system tools to use the new technology." The port was originally unveiled last month at the 2009 Developer Summit in Cambridge. Slides from that presentation are available via the Dev Summit wiki.
Bad Apple (Score:5, Funny)
Always taking from the open source community, and never giving back!
Re:No. Really? (Score:5, Informative)
Yep, apple didn't give back all their code on WebKit, or all of Darwin, or all of launchd, or all their patches on zfs, or their code on MacPorts, or darwin streaming server, or CalDav, or iCal format, or their Calander server, or their code on their X server, or their code on ruby, or a bunch of code on smart card services...
Wait, yes they did.
Re: (Score:2)
all their patches on zfs
Did they really have a choice there?
Re: (Score:2)
They could have chosen not to ship with zfs support.
Given how little OS X supports zfs, they could have left it out without any big deal.
Re: (Score:2, Interesting)
So any modifications to ZFS that they included in their shipped product had to be distributed? GEEE THANKS FOR THAT APPLE and isnt webkit based on khtml?
Re:No. Really? (Score:4, Informative)
Re:No. Really? (Score:5, Insightful)
They are not mini-stallmans. They are Apple Haters (Score:5, Interesting)
It's a win/win, but the mini-Stallmans will never see it that way.
To the contrary: I am a huge fan of Stallman's philosophy and see Apple's work as win/win.
The people that are complaining are the looney Apple Haters, who try and find any point possible by which to attack Apple - never realizing until it is to late the latest position they are attacking from makes no sense.
Please do not taint all those of us who respect the GPL with the same brush the Haters paint themselves in corners with.
Re: (Score:3)
Uh, yes? Sure, you *made* them give up their source if they used your project, but that doesn't change the fact that they *did* use your project, and then contribute back hundreds of thousands of improvements. Or are you suggesting that khtml without apple's assistance would be in the position WebKit is now?
Re: (Score:2)
"this stuff that they improved, they didnt invent it so improving it doesnt count!"
also known as:
"I'm dont understand open source"
Re: (Score:2)
Actually what I'm saying is that just because they play by the rules doesn't make them special.
They use the best software available to them for the job they want to complete. If that happens to be an open source product then they are going to use the open source project. If they use an open source project they are going to want to fix and improve it. With open sources fixes and improvements must be contributed back to the community. They do not deserve any special acknowledgement because they are doing t
Re:No. Really? (Score:4, Insightful)
When is the last time that Apple released an entirely new project? For example Sun released ZFS under the CDDL.
Why reinvent the wheel? They adopt it, improve it and release the improvements. At least they add. They deliver. When is the last time Stallman released an entirely new project? Or finished one? "Although nearly all components have been completed long ago and have been in production use for a decade or more, its official kernel, GNU Hurd, is incomplete and not all GNU components work with it." from the reliable-as-ever Wikipedia. Apple is not Stallman. They do not serve the same market. Apple is in hardware/software/platform, Stallman is in philosophy. Fair enough, einen Unterschied muß es geben.
Re:No. Really? (Score:4, Insightful)
Well, we have the subject of this article, Grand Central Dispatch. We also have Darwin & XNU, their version of the Mach kernel. There is also Bonjour, their version of zeroconf, and their streaming server (Quicktime Streaming Server). They also purchased the source to gimp-print (now called Gutenprint) so they no longer have any obligation to keep it open source, but they do, and they keep releasing the source. How much more do you need?
Re: (Score:2)
Well, we have the subject of this article, Grand Central Dispatch. We also have Darwin & XNU, their version of the Mach kernel. There is also Bonjour, their version of zeroconf, and their streaming server (Quicktime Streaming Server). They also purchased the source to gimp-print (now called Gutenprint) so they no longer have any obligation to keep it open source, but they do, and they keep releasing the source. How much more do you need?
I agree, they could go closed/proprietary like Opera, yet they choose to keep things open and improve on them. They're in it for the money, like a lot of companies, and if that means cooperating with OpenSource Software, so be it. It's a bit of a win/win situation. It's just that their business-model does not allow to go fully free and open, bit of a shame, but oh well, one can't have ones cake and eat it.
Disclaimer: former Apple employee, now in education and liking all things open and free, but still wit
Re: (Score:3, Insightful)
In the mean time... When is the last time that Apple released an entirely new project?
You do realise this article is *about* apple releasing the source code to libdispatch?
Re: (Score:3, Funny)
But apart from CUPS, LLVM/clang, Webkit, Darwin, launchd, patches for zfs, MacPorts, darwin streaming server, CalDav, iCal, the Calendar server, code for Ruby, code for X server and GCD, what has Apple ever done for us?
Re: (Score:3, Informative)
Webkit is kinda special. For ages, Apple did nothing other than releasing the full source every time they released binaries.
They did _not_ release anything under SCM control, which meant tracking patches etc was _literally_ impossible for the KDE team. No matter what the KDE team did or how often they asked, this did not change. This is a large part of why KHTML and Webkit are as different as they are now. Using both KHTML and the Webkit Kpart in KDE 4.3.2, I can tell you that there are a lot of little diff
Multicore Enhancements!! :) (Score:5, Interesting)
Re:Multicore Enhancements!! :) (Score:5, Informative)
Ars Technica has a great overview [arstechnica.com] of what GCD is, and why it's important.
I haven't done much multithreaded programming in C, although this looks like an absolute godsend to those who do. Maybe someday we can actually have a modern desktop as responsive as BeOS was...
The article also contains a bit of information about Apple's compiler strategy and refinements to the C language itself. Most of these have been open-sourced under a permissive license, which is pretty damn cool.
Re:Multicore Enhancements!! :) (Score:5, Insightful)
Maybe someday we can actually have a modern desktop as responsive as BeOS was...
BeOS was indeed very responsive, but it was also notoriously difficult to program for. Apple seems to have done a great job at creating a powerful framework, while keeping it easy enough to be actually used by the developers.
Re: (Score:2, Informative)
Ah, but the benefit of Grand Central is that you don't need to worry (as much) about thread synchronisation and message passing. Just give it the blocks of code that are independent of each other, collect the results, and you're done. Think of it as giving you a ready-made scaffold; sometimes, it's more efficient to build your own that matches your needs more closely, but usually, it's just simpler to use what's already there.
In other words, the whole point of Grand Central is that you don't need to worry a
Re:Multicore Enhancements!! :) (Score:5, Informative)
While you certainly don't deserve a "Troll" rating, the real improvement GDC brings over current implementations of concurrency is that one central authority is aware of all GDC enabled applications, and can therefore make decisions with knowledge of the entire system load and its capabilities when spinning of threads. When you spin of threads independently in each app you have to guess what the rest of the system looks like. You also have to either guess, investigate or have the user configure the general capabilities of the system.
Re: (Score:2)
It takes into account every other libdispatch enabled app. As per the spec.
Re: (Score:3, Informative)
Re:Multicore Enhancements!! :) (Score:5, Insightful)
GCD is far more encompassing than just spawning threads. It's mainly a library for task-based parallelization (my wording, not theirs) and has some other goodies in it as well.
For starters, unless it's not apparent by now, just spawning a new thread to run every such job is too heavy. Scheduling a new GCD job (and all of them will get run on one of a bunch of thread pool threads) is on the range of tens of CPU instructions; on Mac OS X, where GCD originated, spawning a new thread steals away in the vicinity of one megabyte (I can't seem to find an exact number) just for various bookkeeping. That's a lot of setup; even if there's a lot of fat to cut there, the best solution is probably not to spawn a new thread every time.
The API is also very neatly designed. Tasks can be created and added to groups or queues and run synchronously or asynchronously. Semaphores, queues and event sources (which will trigger the addition of an event handler to a queue automatically) can all be paused and resumed to more easily control the flow. Neat, especially combined with the creation of queues that you set up to just funnel work onto another queue.
Add to that the existence of several global queues with varying priorities (corresponding to a set of worker threads at each priority) and the potential for smarts for a system that can see the entire picture with regards to load within the program and across the system. I don't know the extent to which such smarts exist already, but I think you'll agree that with more metadata available, such a scheduler would be better equipped than one fiddling with coarser-grained threads.
So yeah, this is nothing like "just" spawning threads. (I've never worked directly with pthread; it may very well reuse threads, but it didn't look like it from the man page you referred to.) None of it, as far as I can tell, is Apple inventing something new and breakthrough, but it's still a damn good API with a good consolidated set of computationally cheap features whose level of abstraction solves problems.
Re: (Score:2)
*slow clap*
Re: (Score:2)
So far as I can tell, from a .NET guy perspective, GCD is for OS X what Task Parallel Library [wikipedia.org] is for .NET. Or Parallel Patterns Library [microsoft.com] for VC++ - Microsoft implemented C++0x lambdas in VC++10 mainly for that, in fact, just as Apple added blocks to their gcc fork mainly for GCD. Even the terms mostly match - futures, tasks, task groups.
Which is good, I guess, since it means that skills obtained with one would be easily transferable to another.
Re: (Score:2)
I'm a .NET guy too and I've used PFX in production. I think both PFX and GCD are brilliant and are mostly on par when it comes to functionality, but I think GCD may actually be the neater looking API. I'm sure I could have done some of the things I did with GCD's queues in PFX all this time, but I would have never actually thought of it because it'd require separate task managers and task factories and so on. It took me ten minutes to remove almost all locks from a small Cocoa app I had (serialized access t
Re: (Score:2)
I'm a .NET guy also. This sound similar as ThreadPool.QueueUserWorkItem [microsoft.com] and couple of delegates. Or am I horribly mistaken?
Re: (Score:2)
Of course there are still thread pools at the bottom of it, but task is not just a thread. It's a unit of work on a thread that may optionally yield a result (i.e. it can be a future). It can have its status polled, it can be canceled, it can be chained with other tasks to form a pipeline, and you can wait on one or all tasks in a set. And all this doesn't require any explicit locking.
Also, presumably, task scheduler is somewhat smarter than thread pool when dealing with logically grouped tasks (since it kn
Re:Multicore Enhancements!! :) (Score:5, Insightful)
Been there, done that on Solaris and Linux 10 years ago in plain old C. No magic required, just
and away you go.
Piece of cake! Of course, you have no idea how many other processes are tossing threads at their workload and so have no idea if this is a great time to spawn another 8 to really load out the CPU or whether you should just spawn 2 and let some other processes have their time. That's what GCD buys you.
Re: (Score:3, Insightful)
So does Linux need that, do they think about implementing something similar, porting it or what is happening?
Re: (Score:2)
So does Linux need that
It does, but they may not realize that at this point. That's okay - historically, there have been quite a few things which were dismissed with a hand wave for a long time, until suddenly it's the next big thing in Linux land. I recall how that happened for Unicode support, for example.
On the other hand, this means that FreeBSD gets to be the testing ground, and the inevitable eventual Linux port will be more mature and better polished.
more mature and better polished? on linux? (Score:2)
Re: (Score:2)
YA, RLY, pretty much as usual.
Re:Multicore Enhancements!! :) (Score:4, Informative)
In your zeal to take one statement out of context, you missed the point of the framework. Using dispatch queues, I don't have to create threads, an expensive operation, and I don't have to agonize over performance profiles to determine the right number of threads to use. The operating system automatically maintains a global pool of worker threads based on available system resources, and you submit an asynchronous block of code which the system will assign to a thread and run for you based on current system state--that's what the "automatically distribute their work across all available cores" part means. Quite different from merely creating a pthread. Your code will run in an optimal number of threads for the system it's on, whether it's a Mac Mini Core Solo or an eight-core Mac Pro.
You can even distribute the iterations of a for-loop across queues using dispatch_apply(). Imagine doing a lot of expensive work on items in a collection, automatically threaded for the cores of the system it's running on. Here's an intro to Grand Central Dispatch [mikeash.com]. The followup articles on the site are also recommended.
The API to submit a block for asynchronous execution is very simple:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
do_something_computationally_expensive();
});
Posting anonymously since my "bonch" account has been modbombed.
Re: (Score:2)
Gee, I've used pthreads quite a bit and I didn't ever notice the nicely organized thread queue infrastructure. Or anything else in GCD, actually. And I sure don't remember parallelizing a FOR loop with one or two lines of code with it.
GCD is NOT a thread library.
Comparisons? (Score:2)
No because they are different (Score:4, Informative)
GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).
The other two things you mentioned are ways for programs to more easily use multiple threads, but they are still threads under the main process and not centrally managed - so you have to decide blind how much of the system you can take for your threading needs.
You can compare the Blocks syntax to ways those two systems specify work units to be done in parallel, but that is just a part of the story.
Re:No because they are different (Score:4, Interesting)
This is what most people talk about, and what is most obvious from the name, but it is not the interesting part of GCD.
The interesting part of GCD is blocks and tasks, and it is useful to the extent which it makes expressing parallelism more convenient to the programmer.
The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads. This is only useful because OS X has horrendous per-thread overhead. On Linux, for instance, the correct answer is usually to create as many threads as you have parallel tasks and let the OS scheduler sort it out. Other operating systems (Solaris, Windows) have caught up to Linux on this front, but apparently not OS X. If you can get the overhead of OS threads down to an acceptable level, it is always better to avoid multiple layers of scheduling.
That is more interesting but not what is different (Score:2)
The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads
True enough, but it is the part that differentiates GCD from the other frameworks and thus deserved the most explanation.
This is only useful because OS X has horrendous per-thread overhead.
Actually it's useful because threads on all platforms have overhead, which is why the reuse of them by GCD to run these lightweight blocks matters. It's why it's being integrated into BS
Re:That is more interesting but not what is differ (Score:4, Informative)
This is between one and two orders of magnitude more expensive than adding a block to a work queue with GCD.
Switching between the threads is also relatively expensive. At the very least, you need to save all of the registers and update the stack pointer (probably in response to a timer interrupt, so also factor in the cost of a transition from kernel space to users pace). With GCD, the kernel will give you one thread per CPU for each priority level (or fewer if there are already lots of CPU-bound threads), so you minimise number of context switches.
This is effectively what an N:M scheduler does, but is slightly better. With an N:M scheduler, you are switching between some threads in userspace, which saves some overhead, but the threads still have largely-disjoint working sets and so you end up with more cache churn (performance killer on modern CPUs). With GCD, you will only be switching between work queues in a given thread between blocks, so there is no cache churn (the old block's cache lines are no longer needed, so you'll kick them out but not then bring them back in immediately). The other nice side effect of this is that, because GCD knows which work queues are assigned to which threads, it can remove locks used for passing messages between work queues if both queues are in the same threads.
In short, it's an N:M threading model with preemptive kernel threads and cooperative userspace threads. If you read an OS textbook, you'll see that this is, at least in theory, about the most efficient scheduling model possible.
Re: (Score:3, Insightful)
GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).
er... isn't that what modern preemptive multi-tasking OSes already do?
Sort of, but GCD is about what application developers can do. Using current development methods the average developer decides how many threads to spawn and the OS tries to give them all equal priority. Further if you break your app into too many threads performance drops because of management issues. If you break it into fewer threads than there are cores, cores sit idle.
GCD lets app developers break up their app into chunks that can be threads or can be the same thread and let the OS decide how far to brea
Re: (Score:2)
and the OS tries to give them all equal priority
Um, no. At least Linux gives I/O-bound threads higher priority than CPU-bound threads, so that when a thread that is blocked waiting for I/O has some data to process, it preempts any running CPU-bound thread. Whether a thread is I/O-bound or CPU-bound is determined dynamically, by looking at the execution pattern.
Re: (Score:2)
Um, no. At least Linux gives I/O-bound threads higher priority than CPU-bound threads, so that when a thread that is blocked waiting for I/O has some data to process, it preempts any running CPU-bound thread.
Okay, that was an oversimplification. The point being, the app doesn't have information about the system it is running on unless it does complex polling and it doesn't have information about the OS and other application's threads, to schedule them based upon need without creating threads that only increase management overhead.
Re: (Score:3, Insightful)
Re: (Score:2)
Much of what the GCD descriptions seem is "let's compare this well designed system to a badly designed system, and by implication presume that all threading schedulers are also badly designed".
That was not my intention, but I can see where you'd get that idea from my oversimplification. I was trying to point out a couple of main points. One, GDC is a thread pool that is aware of all the threads from the OS and all the apps and the available hardware resources before threads are created. Two, GDC enables developers to easily make their existing applications more fine grained tasks with little work.
Essentially you're going from very coarse grained parallelism to a finer grained parallelism. which gives more flexibility. But people have been doing this stuff and dealing with its problems for decades.
Absolutely, they have, but in actual practice without really using the two items I mention above. Th
Re: (Score:2)
I don't claim that Windows thread pools are equivalent to GCD, but you can have the OS handle asynchronous tasks using the thread pool without having to concern yourself with threads explicitly.
Re: (Score:2)
On a thread level, yes. GCD works with tasks/jobs on a smaller level. I don't know if it actually manages its operation system-wide, but it could certainly do it more efficiently with more metadata and finer-grained units of work.
Nope (Score:2)
er... isn't that what modern preemptive multi-tasking OSes already do?
Modern OS's move applications or (even threads) across different cores. But applications can have many threads, and the threads until now have been mostly managed by the applications themselves. The choice to spin off 10 or 100 threads? Up to the application. And that choice was made without the application being able to understand what choices other applications had made... the OS was left to manage as best it could with a large pil
Re: (Score:2)
Close.... With GCD, you don't create any threads. You create work queues. Those work queues may or may not be backed by one thread, ten threads, or thirty threads, depending on the OS, depending on the number of CPU cores, depending on the number of other processes competing for CPU time.... You get the picture. The point of GCD is that work queues are nearly free,
Re: (Score:2, Informative)
Re: (Score:2)
How about Java? (Concurrent maps are very "cute").
Re: (Score:2)
Has anyone written a comparison of GCD, Intel Thread Building Blocks, and VC++ 2010's own task-based concurrency library?
One thing that comes to mind immediately is that GCD uses Apple's own extension to ISO C for closures (which, IIRC, they have already submitted for standardization - though how long this may take is an interesting question), which means that GCD is usable from a plain C application.
Parallel Patterns Library (VC++2010 analog) is a strictly C++ library, where tasks and task groups are classes. Consequently, Microsoft also extended C++ with closures for that, but rather than build their own, they simply took l
OpenMP (Score:2)
It's unclear that this buys you much over OpenMP 3.0. GCD gives you a little bit more flexibility, but that's not needed in many applications, and GCD is quite inconvenient without closures.
Re: (Score:3, Interesting)
it seems like the ability to share work across machines, not just cores, would be a critical difference.
you're imagining things (Score:3, Informative)
it seems like the ability to share work across machines, not just cores, would be a critical difference.
Neither GCD nor OpenMP allow you to "share work across machines".
Re: (Score:2)
No, but Apple's distributed objects implementation lets you do some pretty cool stuff on that front.
Re: (Score:3, Informative)
http://en.wikipedia.org/wiki/Xgrid [wikipedia.org]
Re: (Score:2)
Except that it does have closures, only Apple prefer to call them blocks. The Cocoa APIs have been extensively revved to include many block-based enhancements to existing APIs that previously used more awkward callbacks.
GCD is not multithreading, it's thread management (Score:5, Informative)
Grand Central is not introducing multithreading - it's introducing comprehensive thread management. So, how many threads are you going to spin for that task? Too many, and you waste a lot of time on thread management and preemption. Too few, and you have processors sitting idle. Now how will you handle this with multiple CPU's? Multiple cores? Hyperthreading? Different cache amounts and layout? OpenCL and GPU processing? Do you know what the rest of the operating system is doing to plan appropriately?
In short, your program can at best make a stab at these issues, and possibly even do a reasonable job if you put a lot of time, effort, and profiling into it. Or you could just use GCD, and let the framework handle it all for you, regardless of whether you're on a Core Solo Mac Mini or a Mac Pro with mutliple OpenCL graphics cards.
It's good stuff. And Apple gave it to the community (much like WebKit enhancements, launchd, etc).
Re: (Score:2)
Do I understand it correctly if I oversimplify it as "centralized thread pool"?
Re: (Score:2)
It has one, but it's not "just" one. For one thing, it's got an event model for creating and coalescing jobs to automatically schedule on a queue, for watching signals and I/O activity. There's more than that, too, like being able to create new queues, target them onto other queues and pause a queue for further execution.
Re: (Score:2)
...It probably won't benefit single cores at all...
Actually, it should reduce management overhead for applications on a machine using a single core.
Re: (Score:2)
I also think it's a great idea because it's a library. Meaning that if it is updated for speed, stability, etc. it can be incorporated automatically on the next compile.
Or, if you're dynamically linked with the library containing it, incorporated automatically when the library is replaced, with no recompilation needed.
(Yes, I know, automatically picking up improvements and automatically picking up shiny new bugs are both enabled by dynamic linking.)
Re: (Score:3, Insightful)
when we start using octal cores
High end workstations are already shipping with dual quad (8 cores total) and will probablly be shipping with dual hex (12 cores total) in the not too distant future. Quad core is fairly common in the midrange and is even available on some fairly low end machines (e.g. the dell vostro 420). Laptops and low end desktops are generally shipping with dual cores.
With the exception of nettops and netbooks single cores are pretty much history.
The bottom line is that cores aren't gett
What is this? (Score:2)
Re: (Score:2)
Is this just apple "inventing" kernel level threads or is it something new?
This is Apple making optimization of threading to multiple cores and GPU's easy for developers. This is a library to take work off the shoulders of developers for making faster, more efficient programs by letting developers chunk up their app and letting the OS (which has more information) make choices for the applications as to what becomes a thread. It is not a fundamental architecture change or anything new on the level you're talking about.
Re: (Score:2)
It's a system of centralized thread queues combined with a nice syntax for easily creating work units to feed to those threads. Yes, bits and pieces of GCD are available in other ways but, as is usual for Apple, they've taken a bunch of existing ideas and put them together into a really nice, integrated package.
Missing Slashtod tag: "greenspun". (Score:2)
Awesome! They have almost reinvented lexical closures, etc. In another ten years this will be as awesome as using continuations for UI navigation in a web framework, which was done yesterday.
Thank goodness for the GPL (Score:4, Funny)
Thanks goodness for the GPL, or we might never have convinced Apple to release its code so that FreeBSD could use it!
Wait... what is that? Oh, nevermind then...
Re: (Score:2)
Thanks goodness for the GPL, or we might never have convinced Apple to release its code so that FreeBSD could use it!
Wait... what is that? Oh, nevermind then...
I have mod points, and I could have just modded this up; however, I am committed to moderation with integrity, however much I might agree with the statement being expressed.
I will, however, simply say this.
BSD was here before you, Richard Stallman. It will be here after you.
Re:Thank goodness for the GPL (Score:4, Informative)
Re:They should use clang instead of GCC (Score:4, Informative)
Re: (Score:2)
Apple maintains their own gcc fork which supports blocks/closures.
The probability that Apple migrates away from gcc is approaching 1 at great speed.
Comment removed (Score:4, Interesting)
Re: (Score:2)
Re: (Score:3, Interesting)
why won't gcc take the patches?
Re: (Score:2, Informative)
Because Apple is sticking with GPLv2
You're missing the point (Score:3, Informative)
Re:They should use clang instead of GCC (Score:5, Informative)
A massive case of NIH from the GCC team with regard to Apple. See also the patches that Apple submitted well over a year ago adding declared property support to GNU gcc. I found it easier to write all of the code required for clang to support the GNU Objective-C runtime than make even small changes to Objective-C support in GCC (in spite of not having used C++ for a few years and really hating the language).
Oh, and I've had blocks working with clang on FreeBSD for quite a while (since several months before Apple publicly released an OS supporting them, in fact). I added the required runtime library support into Etoile's ObjectiveC2 framework a while ago, which also provides the run time support for most of the Objective-C 2 features. This framework is going to go away soon, because I'm now maintaining a fork of the GNU Objective-C runtime in the GNUstep repository, which merges these improvements and also incorporates most of the ideas from my experimental Objective-C runtime library (without breaking backwards compatibility, although you don't get all of the features if you don't use the new ABI).
By the way, porting to *BSD is much easier than porting to Linux. Libdispatch is based around the kqueue mechanism for unifying kernel event sources, and there is currently no in-tree equivalent for Linux. There are four out-of-tree sets of patches providing equivalent functionality (that I know of, there may be more), as is common with Linux development. On Solaris you can do the same thing with completion ports, which are roughly semantically equivalent but have a different interface.
Re: (Score:3, Interesting)
It goes further and deeper(and uglier) than that. Remember when Apple released the G5's? Apple actually submitted patches to GCC, but they were declined, with GCC's official stance being "It would reduce GCC's portability". However, a few weeks later, IBM submitted some patches for GCC, that were summarily accepted. IBM's patch package contained many of Apple's patches for GCC.
Re:Apple's Grand Central Dispatch Ported To FreeBS (Score:3, Funny)
Re: (Score:2, Insightful)
Netcraft confirms it: This joke is dying.
Re: (Score:2, Funny)
Re: (Score:2, Informative)
On their stolen computer next to all the other things they stole from school. They even steal the flies from outside who swarm around their unwashed bodies. linux is the devolvement of humanity - a linux user is like an anti-human - taking the opposite form of what a real human should be. They do not know how to reproduce, they cannot interact with others and they long ago forgot the concept of personal hygiene. They believe communism is something we should strive for and believe klingon is a real langu
Re: (Score:2)
I'm not an expert but I think this now opens up multi-core to individual applications. Before, the OS and system managed which processes should be passed to cores based on threads. Now with GCD, applications can be written that blocks of code could be flagged so that the OS can know to passed.
The example given in Wikipedia is the analyseDocument method which is used in a document to count the number of words. Without GCD, the main thread that runs this method will have to wait until the method is done.
Re:In other news... (Score:5, Funny)
Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his freedom.
Re: (Score:2)
Richard Stallman does not cry into his beer. Microsoft cries into their beer. Richard Stallman cries into his speech.
Fixed that for you.
Re: (Score:2)
So, in other words, sobbing.
And yeah, I messed the simile up.
Re: (Score:2, Funny)
But when he shaves (Score:2)
does he get derivative works?
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
That's not quite correct. There are two parts to GCD: libdispatch and the kernel support. The kernel support is MIT license, so is compatible with GPL. Besides, the kernel component wouldn't be ported anyway--it would be rewritten from scratch if one were doing GCD Linux, so the license doesn't matter.
Libdispatch is Apache license. It runs in the applications, not the ke
Re: (Score:2)
And unless someone has benchmarks, I suspect the performance edge of Grand Central Dispatch isn't going to obsolete Linux - or for that matter, Microsoft Server - overnight.
Re: (Score:2)
Yeah, you beat me to it. Sounds like another case of confusing copyright with patents.
Re: (Score:3, Insightful)
If you're creating a serial queue anyway, you no longer have parallelism. If you have multiple serial queues, you may as well have had multiple threads with no interlocking between them. This is just yet another API to do what competent parallel system programmers have been doing since the first thread.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
It will support C++ soon enough.
The benefits of clang are that it uses llvm as the compiler, which produces better optimized machine code than gcc currently does. Also, it supports Apple's block syntax (kind of like a pointer to a function), which allows things like libdispatch to do its magic. Also, as a C front end, it has much less cryptic error messages, and actually does a pretty good job of finding missed initializations and other hard to find bugs that usually will get caught at the code execution