On Sun, 21 Feb 2010 17:10:34 -0700, Alex Rousskov <[email protected]> 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
