Re: SMP: inter-process communication

On 02/21/2010 06:10 PM, Henrik Nordström wrote:
> sön 2010-02-21 klockan 17:10 -0700 skrev Alex Rousskov:
>
>> The only inter-process cooperation I plan to support initially is "N
>> processes monitoring the same http_port (and doing everything else)".
>
> I guess there will be no shared cache then?

Not initially, but that is the second step goal.

>> 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.
>
> Not without restarting the worker processes no.
>
>> If you think a different approach would be better, please let me know.
>
> If things gets broken down like follows:
>
> * Forwarding processes. Listens on an http_port. Processes protocols.
> Forwards requests. Limited internal caching.
>
> * Persistent Object Caches, disk and/or memory
>
> * ICP/HTCP
>
> * DNS Cache
>
> each with their own process, then for most purposes, 'a' would work
> fine. A config change involving http_port changes then sets up new
> worker processes for those ports and tells the existing ones to shut
> down.

I agree in general, although I am not sure using processes dedicated to
 ICP or DNS caching is worth the overheads. These details are not
important for now though.

If we go with (A), that is "create all sockets you need to share and
then fork() processes", the processes still need a mechanism to
communicate with each other. For example, a forwarding process needs to
communicate with the cache process. This can be done using those
pre-created [Unix domain] sockets, I guess.

What does (A) buy us? (A) makes it is easier to pre-arrange how
processes communicate with each other, right? Any other advantages?

As we discussed, (A) makes it more difficult to support some
reconfigurations as some processes need to finish all the current
activities and then quit nicely while other, new processes start up in
their place. This affects significant portions of the code and is not
something we currently support (at least not nicely). Also, it may
significantly increase CPU and RAM requirements when two process
categories co-exist (old dying and new ones).

Is (A) really better than (B)?

Thank you,

Alex.
Received on Mon Feb 22 2010 - 03:18:34 MST