Re: SMP: inter-process communication

On Sun, 21 Feb 2010 17:10:34 -0700, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> 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).

I think Roberts concept of a spawn process offers some benefits for the
implementation of this.

 Ending up with a process that does all the spawning and sends back
control FD for each child process (of any type). The interior API would be
something along the lines of a spawn_process(binary-path,
struct-to-receive-FDs, [callback-to-receive-FDs]).

The problems as Henrik mentioned is Windows, so all this pending Guido's
feedback on what the possibilities there are. Although with a simple API
interface like above, we could plug-in several fork implementations where
available.

Amos
Received on Mon Feb 22 2010 - 01:21:59 MST