c - 管理加载到内存中的共享库的设计模式

Question

gcc (GCC) 4.7.2

你好，

我正在开发一个大型项目，其中包含我将开发的 2 个模块(共享库)。

这些模块是我在 C 中创建的共享库，它们必须在彼此之间同步和交换消息。

管理器模块将控制这两个模块 (.so) 并将其加载到内存中。如果一个人失败了。管理员可以尝试重新加载它。

我想知道，因为这是我第一次做这样的事情。有没有可以遵循的设计模式？

所有这些都将用 C 语言编写，并使用 APR(Apache 可移植运行时)进行内存池管理，如果需要，可能还会使用一些线程池。

1. 启动将加载两个模块的管理器。
2. Manager 然后对它们调用一些函数来启动和停止它们，并可能进行清理。
3. 一旦两个模块都已加载并启动。他们应该能够在彼此之间交换一些消息。

所有模块都将在运行 Redhat 的同一台机器上运行。

非常感谢您的任何建议。

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.

如果它在单个 C 进程中，这通常是一个坏主意 - 如果其中一个模块出现故障，您不太可能能够安全地卸载它，更不用说再次加载它了。如果您需要能够从模块故障中恢复，则必须使用独立进程。代码仍然可以在 .so 文件中 - 只需 fork() 管理器一次即可加载每个模块；例如，这是 chrome 插件 API 使用的模型。

此外，处理组件故障本身可能非常非常棘手。仅仅因为 A 重启并不意味着 B 准备好与新重启的 A 交谈。您可能想尝试收集一些想法 erlang ，它通过鼓励将应用程序分解为具有主管模块层次结构的消息传递子组件来重新启动故障组件，从而非常好地处理组件故障。如果您只有两个模块，这可能有点矫枉过正，但至少值得考虑。

至于如何沟通，有多种范式。如果这些模块在同一个进程中，你可以传递一个 vtable。也就是说，例如:

// 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();

您的经理会加载两者，将 vtable 从 A 传递到 B，反之亦然，然后调用启动例程。订购时要小心 - A 必须在 B 准备好之前启动，反之亦然，他们需要同意这一点。

如果它们在独立的进程中，消息传递通常是可行的方法。那时它本质上是一种网络协议(protocol)——您的子进程将向管理器发送序列化消息，然后管理器将它们路由到其他子进程。对话可能看起来有点像这样:

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!"

请记住，除了上面的示例之外，还有许多其他方法可以构建这种协议(protocol)，并在消息传递协议(protocol)之上构建 RPC。您可能有兴趣查看诸如 DBUS 之类的内容(您可以直接使用!)或 DCOM ，以前做过这种事情。在此类协议(protocol)之上的其他优化包括使用管理器在 A 和 B 之间建立某种直接 channel ，并且仅当 A 或 B 需要重启时才再次参与。

也就是说，在弄清楚管理器需要做什么之前，不要深入了解管理器的工作原理。设计插件<->管理器高层接口(interface)，以及插件<->插件协议(protocol)；然后才设计插件<->管理器接口(interface)的细节。太容易分心并最终得到像 CORBA 这样过于复杂的东西。或 SOAP .