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.