[Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list...

[J C Lawrence]

On Wed, 02 May 2001 10:02:38 +0100 
Nigel Metheringham <Nigel.Metheringham at InTechnology.co.uk> wrote:

> claw at kanga.nu said:

>> The standard *nix approach is to use the process ID which is
>> guaranteed unique.  If you're not running an *ix, just have one
>> process use numerically even tempfile names, and the other odd.

> Actually you would be better advised to go the Maildir filename
> approach - the filename is made up of the time(), the pid and a
> machine specifier of some form.  

Not a bad idea as it makes the resultant filename self-documenting.

> That won't have clashes unless you can wind through your pids in
> under a second (although the current proposals for random pids
> worries me somewhat).

I haven't looked at PID allocation strategies for a while now, but
last I looked most systems used an incrementing counter for PIDs,
rolling over to 2 on overflow (zero and one are special pids), which
checked for collisions on each increment (to prevent collisions
after the PID counter has wrapped at least once).  Given that pid_t
is typically at least a 16 bit value, that means you'd have to
create destroy 32767 processes within your time slice (pid_t is
usually a 32bit or 64bit value on modern systems, making for a much
larger loop time).

I've not run into random PID allocation strategy proposals.  Very
odd idea.  Doing a quick google search suggests Marek was trying to
protect lame tool authors who use the PID in sensitive data control
situations and got soundly slapped in the process.

-- 
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--