Question

I have legacy application code written for a real-time operating system (RTOS). Most of the code uses an OS-Specific Inter-Process-Communication (IPC) call, that looks very similar to a signal.

It has two IPC calls:

• status_code signal_push(connector, event)
• event signal_wait(connector)

I want to slowly port that application to Linux in order to improve testing and debugging.

I want to create a task-description file, that covers tasks their associated IPC primitives with events and handlers.

An example would look like this:

SignalHandler(connector=crypto_connector, 
              events = [(cyrpto_init, crypto_init_handler),
                        (crypto_run, crypto_run_handler),
                        (crypto_done, crypto_done_handler]) 

Task(name=crypto, priority=1, stack_size=256, connector=crypto_connector)

From this description file it should generate a thread for each task that calls the corresponding handler, that is written by an engineer. it shall also generate call stubs similar to emit_crypto_init()

It is quite clear to me what kind of code I shall generate from this description for the RTOS but I’m still uncertain, what kind of IPC I should use for Linux. For the first version probably anything that keeps behaviour is okay. For future versions, it could be plausible to use Linux on target and therefore the IPC should have little overhead.

I found the following IPC mechanisms:

• Unix signals (seems as if it is not an option)
• Unix sockets (do a lot more than just sending a signal)
• semaphores (do less, but we could use global integers to pass the event to the other party)

Are there more suitable IPC solutions out there, that could fit this requirement?

Answer 1

There are several possibilities:

• Boost Signals (not to be confused with Boost Interprocess) – http://www.boost.org/doc/libs/1_51_0/doc/html/signals.html, other is
• cpp-events http://code.google.com/p/cpp-events/
• libsigc++
• Qt Signals and Slots