Re: SMP: inter-process communication

On 02/21/2010 02:45 PM, Henrik Nordström wrote:

> I guess the main question to ask is interaction between processes.
> Mainly sharing of cache etc. How do these impact the chosen model?
>
>
> In the longer term model I see that we will have several cooperating
> processes, for example
>
> N processes monitoring http_port, forwarding requests. May be several
> different configurations used among these processes.
>
> M processes maintaining caches (object, ip, etc) shared by some/all of
> the above. The exact model how this is done is yet to be determined.
>
> X shared data resources of different kinds with no dedicated process

I agree that the above are realistic use cases that will need to be
supported one way or another. I was planning to post a separate message
about that...

The only inter-process cooperation I plan to support initially is "N
processes monitoring the same http_port (and doing everything else)". I
know of two ways to support that specific use case:

A) One dedicated process starts listening and fork()s other processes
that can then also listen on the same http_port socket descriptor.

B) One process starts listening and sends others the open socket
descriptor via UNIX domain sockets, STREAMs, doors, etc.

I am working on option (B). While more complex, I think (B) is much more
powerful and flexible than (A). For example, (A) cannot efficiently
support reconfiguration when http_ports need changing.

Within option (B), I am leaning towards UNIX domain sockets as an IPC
mechanism. I would prefer to use something that would work on Windows as
well, but I do not know what that would be. Eventually, we can support
more than one IPC mechanism, of course, and Windows have something
similar to Unix domain sockets.

If you think a different approach would be better, please let me know.

Thank you,

Alex.
P.S. For data sharing between the cache and other processes, mmaps may
be an attractive option, but I have not investigated the details yet
(including selection of the best synchronization mechanism).
Received on Mon Feb 22 2010 - 00:10:56 MST