On Wed, 02 May 2001 10:02:38 +0100
Nigel Metheringham <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
---------(*) http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
------------------------------------------------------
Mailman-Users maillist - [EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
