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.

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?

> 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 - 03:39:14 MST