On Tue, 23 Feb 2010 09:45:56 -0700, Alex Rousskov <[email protected]> wrote: > 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?
Yes, but ... we need to ensure the wrapper API fits the possible backend capabilities realistically. Amos
