On 02/21/2010 06:10 PM, Amos Jeffries wrote: > On Mon, 22 Feb 2010 02:03:31 +0100, Henrik Nordström > <[email protected]> wrote: >> mån 2010-02-22 klockan 11:44 +1100 skrev Robert Collins: >> >>> command protocol for it would be pretty similar to the SHM disk IO >>> helper, but for processes. Something like: >>> squid->helper: spawn stderrfd argv(escaped/encoded to be line & NULLZ >>> string safe) >>> helper->squid: pid, stdinfd, stdoutfd >> Which requires UNIX domain sockets for fd passing, and unknown >> implementation on Windows.. >> >>> This would permit several interesting things: >>> - starting helpers would no longer need massive VM overhead >>> - we won't need to worry about vfork, at least for a while >>> - starting helpers can be really async from squid core processing (at >>> the moment everything gets synchronised) >> Yes. >> >> +1 in general, with the reservation that I want to hear back from Guido >> on what options there may be on Windows platform. > > +1 with same reservations.
The above was posted on the "immortal helpers" thread. I am responding to this under SMP subject because the discussion is related to the IPC mechanism selection as well. I agree that we need Guido guidelines on how to pass descriptors on Windows. However, I believe that 1) There is just no single mechanism that would work well on Windows and Unix. 2) The Windows portability problem has been solved by ACE and possibly Apache folks so we can solve it as well. I have seen references to similar-but-different descriptor sharing features available on Windows. Thus, we can proceed without sufficient Windows expertise, as long as the IPC mechanism is declared as a Squid API (and implemented as a wrapper for relevant OS-specific features such as UDS on Unix). I believe ACE uses the same approach. When somebody wants to support SMP on Windows, they would need to provide the right implementation for the IPC on that platform but the rest of the code will remain virtually unchanged. Do you agree? Thank you, Alex.
