Re: SMP: process-specific options

> On 02/21/2010 01:52 AM, Amos Jeffries wrote:
>>>> Other things from my prior thoughts about this design is that it
>>>> implies
>>>> squid-N.pid, and cache-N.log (for now) files with N being the process
>>>> number/name.
>>>
>>> I am not sure it implies that, actually (even for now), but it
>>> certainly
>>> would be an option.
>>
>> Under the current architecture the child is the one in .pid and the exit
>> code determines whether master re-spawns or closes. I was previously
>> working from that angle.
>
> Understood.
>
>> If we invert the current design and have master being the one .pid
>> entry...
>>
>> ... you would be altering the .pid to hold the master PID, which somehow
>> receives the PID for each child back from the child and shuts off the
>> children when it gets a shutdown signal.
>
> The parent process is not in a very good position to do much because it
> block-waits for the kids. It can still handle signals, I guess. Perhaps
> we can change that, but I am not sure we should.

Well, it is not required to block-wait for the kids. someone can use the
WNOHANG in waitpid which does not block.
You can use the following on the master/parent process
while (1) {
          do some (blocking?) work;
          while (There are exited childs) {
                  handle an exited child;
          }
}

>
> A dedicated kid process that handles signals (shutdown, debug,
> reconfigure, etc.) and possibly other coordination tasks may work
> better. That process can communicate to others what they should do,
> either by resending the signal to all of them or using some more
> sophisticated IPC methods.
>
>
>> cache.log depends on how you plan to re-plumb the linkage between master
>> and worker. The current silent process monitoring method is iffy in the
>> middle.
>> What were you planning for monitoring? socket read/write events?
>
> I was not planning on changing waitpid() code in the master process if
> that is what you are asking about.
>
>> If you have each instance completely independent with its own
>> current-style monitor talking to a master instance its easy to plumb
>> cache.log through the link socket, but _that_ means that PID are harder
>> to manage as the worker child is not connected to the sockets directly.
>
> For logs, can we just use O_APPEND and have each process write to the
> logs as we do now?

It will work. An alternative method is:
  - use an external logging process
  - squid child and parent processes share a pipe to the logging process.
It will work because multiple process can share a pipe where there are
multiple writers and one reader (the logging process).
This will simplify the rotation too.

>
>> If the file was open(2)ed with O_APPEND, the file offset is
>> first set to the end of the file before writing. The adjustment of the
>> file offset and the write operation are performed as an atomic step.
>
> Log rotation will probably need special care to avoid rotating the same
> log many times. It is relatively easy to designate one process to do the
> rotation (e.g., squid1), but that alone is not enough to synchronize
> everything. Ideally, I would prefer to avoid locking. Any clever tricks
> applicable here?
>
> Thank you,
>
> Alex.
>
Received on Tue Feb 23 2010 - 10:45:41 MST