Multithreading in GIMP, Learning to write GEGL operations

As some of you have seen, GIMP is being ported to a new graph-based image core, called GEGL. Those of you who have experimented with GIMP 2.6.X and later, have possibly found the GEGL tool (Under the tools menu) which allows you to see on-canvas preview of some operations such as blur, perlin noise (which some of you know as clouds), and more.

Thanks to the very generous help of Øyvind Kolås (aka pippin), I have started to write a GEGL operation for GIMP. Too practice I decided to write a Pixelize operation (not too complex, but also works on a neighborhood of pixels and not on a single pixel).
This is the first time which I implement an image processing algorithm which is not based on samplings for distortion (like the waves filter), and although I know the theory for a lot of time, it still has some bugs with wrong indexes :P

When I finish this, I'm going to post it here along with a log of my chat with pippin on the IRC (on irc://irc.gimp.org/#gegl) to clear out some of the common questions about GEGL. Hopefully I'll be able to post a mini-guide (or more correctly, what I have learned, since I still have a lot to learn to write a full GEGL guide) to introduce other people to writing GEGL operations.

The discussion originally started because I was disappointed that libgimp (the library for interactions between plugins and GIMP) is not thread-safe, meaning that you can't have two threads modifying the same drawable concurrently (unless of course you want to "Create Modern Random Art" as someone called it). And it's impossible not practical to fix it (due to the amount of time it would take).

Apparently, GEGL is multi-threaded (more on this later, in my next post) and it usually works (but sometimes the threads reach a dead-lock, a situation in which both threads are blocking one another from progress since they are waiting for shared resources/memory). It still requires a bit of fixing (Cheer up for pippin! He needs some more motivation to fix this! ;-) )

So, for those of you who want to try "bleeding edge" and unstable GEGL, set the environment variable GEGL_THREADS to 2 (or whatever amount of threads you want GEGL to use) and expect up to 200% speedup (in ideal world. Practically some parts of the code which are executed sequentially, added to the limitation of the memory access speed, both will cause it to run slower depending on the operation and your system) with GEGL (or 0% if you reach a deadlock).
Be warned: this is supposed to be buggy. Please do not report bugs with this, unless you strictly know what you are doing.

Edit: Made the post more correct about the possible speedup. 200% speedup is a naive optimistic view, which is ain't true (and I forgot to mention this)