Fusion:About

Introduction
The original PDF documentation is a bit sparse, so I'll try to flesh it out a bit here. I just wrote down what I figured out while reading its source, so this ended up being a combination of a how-to-use and a how-it-works guide.

Although the fusion library is built as part of DirectFB, it really is a shared library that can be used by others. The fusion library uses the direct library, so be sure to read up on that if you're really trying to understand how fusion is implemented.

As you're learing what fusion is all about, you might want some examples showing how to use it.

What is Fusion?
Fusion provides an implementation of abstractions needed for multi-threaded/multi-process programming:

Abstractions

 * 1) Shared Memory
 * 2) Arena (registry of pointers to shared memory)
 * 3) Reference Counter
 * 4) Skirmish (mutex)
 * 5) Call (RPC)
 * 6) Reactor (event source)
 * 7) Property
 * 8) Vector
 * 9) Object

Fusion Library vs. Device
Fusion consists of two pieces:
 * The fusion library is called in user space by DirectFB (and others)
 * The fusion device is in kernel space and is used by the library to get across process boundaries

In its standard configuration fusion is built to be a multi-app capable library, it uses the software device implemented in a kernel module to accomplish inter-process communication. A simple implementation of fusion is also available for a single process, using ptherad mutexes to build its abstractions. When compiled for single-app usage, only the fusion library is relevant.

When examining the fusion source code, you might want to look at the latter portions of the files for the simple implementation that is compiled when FUSION_BUILD_MULTI is not defined. Once you understand how that works for a single process, it might be easier to see what’s going on with the kernel device in the picture for the IPC stuff.

The fusion module also provides statistical information in the Fusion Proc Filesystem.

Fusionees and Worlds
A process using the fusion library is known as a fusionee. A fusionee may access fusion items created by it or any other fusionee operating in the same fusion world. In the multi-app configuration, any number of processes may be in a given fusion world, of which there can be up to eight (numbered 0 to 7). In the single-app configuration, every fusionee operates in its own world (always number 0), and therefore only uses fusion to communicate with itself (possibly between threads, but all in the same process nonetheless).

Signals and Threads
By using fusion your application becomes multithreaded, regardless of whether you use threads elsewhere in your app (calling fusion_enter creates a fusion messaging thread). And, being a multithreaded app has implications for signal handling which is different for LinuxThreads (common in embedded development) vs NPTL (RH4 and other distros). This can lead to obscure bugs if your app calls routines that use signals (fork/sleep, etc) from the context of the fusion thread (RPC, reactors, etc.). The fusion message thread blocks all signals, assuming that the main thread will do signal handling. However, the LinuxThreads implementation is broken with respect to signal handling so you must explicitly unblock any signals that you expect to receive on the message thread.