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).