Re: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list...
On Tue, 01 May 2001 21:28:03 -0700 Chuq Von Rospach [EMAIL PROTECTED] wrote: On 5/1/01 8:52 PM, Barry A. Warsaw [EMAIL PROTECTED] wrote: I've avoid that because of NFS issues, i.e. if you've got multiple Mailman installations sharing an NFS partition, the pids aren't relevant. If you have that, don't you have chaos anyway? Is the createlink lock style reliable over NFS in the first place? Isn't putting locks from multiple machiens in the same directory just a plain old bad idea? The only operation guaranteed as unique under NFS is creat(). That pretty well limits the options. I ran into a strange little problem today -- I'm using time() to generate a filename for a temporary directory. Works great; until you start running multiple processes on a 2 CPU machine. I started having two processes get the same time() value (which is impossible on a single CPU system) and fight over the same directory. I'm now doing a random() based sleep to get away from this. Bad bad bad bad. You've just decreased the incidence of collisions, not their fact or possibility. 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. -- 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
Re: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list...
Someone wrote (I got completely lost with the attributions in this and can't find the original):- I ran into a strange little problem today -- I'm using time() to generate a filename for a temporary directory. Works great; until you start running multiple processes on a 2 CPU machine. I started having two processes get the same time() value (which is impossible on a single CPU system) and fight over the same directory. I'm now doing a random() based sleep to get away from this. [EMAIL PROTECTED] said: Bad bad bad bad. You've just decreased the incidence of collisions, not their fact or possibility. 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. 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). Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ Phone: +44 1423 85 Fax +44 1423 858866 ] [ - Comments in this message are my own and not ITO opinion/policy - ] -- Mailman-Users maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users
Re: [Mailman-Developers] Re: [Mailman-Users] Big problems with stale lockfiles on large list...
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
