"Multi-process" vs. "single-process multi-threading" for software modules communicating via messaging

Question

We need to build a software framework (or middleware) that will enable messaging between different software components (or modules) running on a single machine. This framework will provide such features:

• Communication between modules are through 'messaging'.
• Each module will have its own message queue and message handler thread that will synchronously handle each incoming message.

With the above requirements, which of the following approach is the correct one (with its reasoning)?:

1. Implementing modules as processes, and messaging through shared memory
2. Implementing modules as threads in a single process, and messaging by pushing message objects to the destination module's message queue.

Of source, there are some apparent cons & pros:

• In Option-2, if one module causes segmentation fault, the process (thus the whole application) will crash. And one module can access/mutate another module's memory directly, which can lead to difficult-to-debug runtime errors.
• But with Option-1, you need to take care of the states where a module you need to communicate has just crashed. If there are N modules in the software, there can be 2^N many alive/crashed states of the system that affects the algorithms running on the modules.
• Again in Option-1, sender cannot assume that the receiver has received the message, because it might have crashed at that moment. (But the system can alert all the modules that a particular module has crashed; that way, sender can conclude that the receiver will not be able to handle the message, even though it has successfully received it)

I am in favor of Option-2, but I am not sure whether my arguments are solid enough or not. What are your opinions?

EDIT: Upon requests for clarification, here are more specification details:

• This is an embedded application that is going to run on Linux OS.
• Unfortunately, I cannot tell you about the project itself, but I can say that there are multiple components of the project, each component will be developed by its own team (of 3-4 people), and it is decided that the communication between these components/modules are through some kind of messaging framework.
• C/C++ will be used as programming language.
• What the 'Module Interface API' will automatically provide to the developers of a module are: (1) An message/event handler thread loop, (2) a synchronous message queue, (3) a function pointer member variable where you can set your message handler function.

Answer 1

Here is what I could come up with:

Multi-process(1) vs. Single-process, multi-threaded(2):

• Impact of segmentation faults: In (2), if one module causes segmentation fault, the whole application crashes. In (1), modules have different memory regions and thus only the module that cause segmentation fault will crash.
• Message delivery guarantee: In (2), you can assume that message delivery is guaranteed. In (1) the receiving module may crash before the receival or during handling of the message.
• Sharing memory between modules: In (2), the whole memory is shared by all modules, so you can directly send message objects. In (1), you need to use 'Shared Memory' between modules.
• Messaging implementation: In (2), you can send message objects between modules, in (1) you need to use either of network socket, unix socket, pipes, or message objects stored in a Shared Memory. For the sake of efficiency, storing message objects in a Shared Memory seems to be the best choice.
• Pointer usage between modules: In (2), you can use pointers in your message objects. The ownership of heap objects (accessed by pointers in the messages) can be transferred to the receiving module. In (1), you need to manually manage the memory (with custom malloc/free functions) in the 'Shared Memory' region.
• Module management: In (2), you are managing just one process. In (1), you need to manage a pool of processes each representing one module.