Fusion:Library

From DirectFBWiki

Table of contents

1 fusion_init() 2 fusion_exit() 3 fusion_kill() 4 message-loop (aka read-loop)

fusion_init()

Before anything else, you have to call fusion_init(). The first parameter tells fusion which world you want to be in, or pass a negative value if you want to start a new world (the last parameter tells you the world you landed in). You also have to tell fusion which ABI version you’re expecting so it can do a sanity check that it’s compatible. Here’s what’s initialized:

1. Initialize the direct library
2. Open the kernel device (create/join the world, and establish your fusion id)
3. Initialize/attach to shared memory (shmalloc) for this world
4. Trap SIGSEGV to allow shmalloc to try to cure the problem
5. Start a thread for the message-loop (see below)

Multiple calls to fusion_init() will not really re-initialize everything. Rather, they will just increment a reference counter so you’ll need to call fusion_exit() just as many times.

fusion_exit()

When done with fusion, you have to clean up with a call to fusion_exit() to undo the stuff initialized with fusion_init(). You can specify whether this is an emergency shutdown, which means that the fusion_read_loop thread is not given a chance to clean up its stuff.

fusion_kill()

You can kill the processes of one or all other fusionees in your world with fusion_kill(). You generally only want to do so if you’re master (i.e. the first fusionee) of your world, but there’s nothing enforcing this. Like the system kill you get to specify which signal is sent to the victim. You cannot commit suicide with fusion_kill() since it will never send a signal to the calling process.

message-loop (aka read-loop)

Calls and reactors require the flow of control to transfer to another fusionee, which may be in another process. The message-loop runs in its own thread where it waits on a message to be available for the fusionee. It does this by blocking on the fusionee’s kernel device until one or more messages can be read (see kernel module read and poll device methods below).

When call (FMT_CALL) or reactor (FMT_REACTOR) messages arrive, the call is made or the reaction occurs (the reaction functions are called) within the message-loop. Each fusionee has its own message-loop, so calls and reactions happen in whichever fusionee created them (which is the whole point, really).

Generic messages (FMT_SEND) have only one purpose so far, which is to wake up and terminate the message-loop thread as part of fusion_exit()in order to cleanly terminate the fusionee. (There’s an extra guard to check the reference count to ensure that fusion_exit() was really called enough to justify terminating the loop).