Question

gcc (GCC) 4.7.2

Hello,

I am developing a large project that will contain 2 modules (shared libraries) that I will develop.

The modules are shared libraries created by me in C, that will have to sync and exchange messages between each other.

The manager module will control and load both these modules (.so) into memory. If one was to fail. The manager could try and re-load it.

I am wondering as this is my first time I have done something like this. Is there any design patterns that could be followed?

All this will be written in C and using the APR (Apache Portable Runtime) for memory pool management and maybe some threading pool if needed.

1. Start manager that will load both modules.
2. Manager then calls some functions on both of them maybe to start and stop them, and possible cleanup.
3. Once both modules have been loaded and started. They should be able to exchange some messages between each other.

The modules will all run on the same machine running Redhat.

Many thanks for any suggestions.

Answer 1

The manager module will control and load both these modules (.so) into memory. If one was to fail. The manager could try and re-load it.

This is usually a bad idea if it’s in a single C process – if one of these modules fail, you’re unlikely to be able to safely unload it, much less load it again. If you need to be able to recover from module failure, you must use independent processes. The code can still be in an .so file though – just fork() the manager once for each module to load; this is the model used by the chrome plugins API, for example.

Moreover, dealing with component failure can be very, very tricky in itself. Just because A restarts doesn’t mean B is ready to talk to a newly restarted A. You may want to try to glean some ideas off erlang, which handles component failure exceptionally well by encouraging the decomposition of applications into message-passing subcomponents with a hierarchy of supervisor modules to restart failing components. This may be a bit overkill if you only have two modules, but it’s something to think about at least.

As for how to communicate, there are a number of paradigms. If these modules are in the same process, you could just pass a vtable around. That is, for example:

// moduleA.h

struct vtable_A {
  void (*do_something)();
};

void set_vtable_B(struct vtable_B *);
struct vtable_A *get_vtable_A();
void start_A();

// moduleB.h
struct vtable_B {
  void (*do_something)();
};

void set_vtable_A(struct vtable_A *);
struct vtable_B *get_vtable_B();
void start_B();

Your manager would load both, pass the vtable from A to B and vice versa, and thereafter call the start routines. Be careful with ordering – either A must be started before B is ready, or vice versa, and they need to be okay with this.

If they’re in independent processes, message passing is usually the way to go. It’s essentially a network protocol at that point – your subprocesses will send serialized messages to the manager, and the manager routes them to other subprocesses. The conversation might look a bit like this:

MGR->A      START
MGR->B      START
A->MGR      REGISTER_ENDPOINT 'ProcessA'
A->MGR      WATCH_ENDPOINT 'ProcessB'
MGR->A      OK_REGISTER 'ProcessA'
MGR->A      OK_WATCH 'ProcessB'
B->MGR      REGISTER_ENDPOINT 'ProcessB'
B->MGR      WATCH_ENDPOINT 'ProcessA'
MGR->B      OK_REGISTER 'ProcessB'
MGR->A      NEW_ENDPOINT 'ProcessB'
A->MGR      APPLICATION_DATA TO:'ProcessB', PAYLOAD:"Hello, world!"
MGR->B      OK_WATCH 'ProcessA'
MGR->B      NEW_ENDPOINT 'ProcessA'
MGR->B      APPLICATION_DATA FROM:'ProcessA', PAYLOAD:"Hello, world!"

Keep in mind, there are many other ways to structure this kind of protocol than the example above, and to build RPC on top of a message-passing protocol. You may be interested in looking at things such as DBUS (which you may be able to use directly!) or DCOM, which have done this sort of thing before. Other optimizations on top of this sort of protocol include using the manager to establish a direct channel of some sort between A and B, and getting it involved again only if A or B need to be restarted.

That said, don’t get too deep into the details of how the manager works before you figure out what it needs to do. Design the plugin<->manager high level interface, and plugin<->plugin protocol; only then design the details of the plugin<->manager interface. It’s far too easy to get sidetracked and end up with something way too complex like CORBA or SOAP.