Re: SMP: inter-process communication

On Tue, 23 Feb 2010 09:45:56 -0700, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/21/2010 06:10 PM, Amos Jeffries wrote:
>> On Mon, 22 Feb 2010 02:03:31 +0100, Henrik Nordström
>> <henrik_at_henriknordstrom.net> 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
Received on Tue Feb 23 2010 - 22:47:32 MST