mailman.git - The GNU Mailing List manager.

	Commit message (Collapse)	Author	Age	Files	Lines
*	This module has been "renamed" to LockFile.py	bwarsaw	1999-08-21	1	-198/+0
\|
*	LockFile.lock(): Two changes: first a minor one, if we raise a	bwarsaw	1998-12-27	1	-7/+27
\| \| \| \| \| \| \| \| \| \|	TimeOutError, we want to unlink our tmpfname first, so we don't potentially leave our linkfile hanging around forever. The second change adds a `stolen' flag which gets set to 1 when we determine a link is stale, and should eliminate the occasional assert errors Ken is seeing. My analysis is included in the comment in the code, but I still wonder if the logic here isn't still flawed.
*	Add small comment on assertion, in light of Ken's complaint of 7-Dec	bwarsaw	1998-12-18	1	-0/+5
\|
*	FileLock.steal(): New method which just basically writes a new PID	bwarsaw	1998-12-18	1	-0/+4
\| \| \| \| \| \| \| \|	into the lock file. USE WITH CAUTION. Necessary because in the new news/mail gating code, the parent acquires the lock, and if successful, the child will steal it from the parent and then unlock it when done. This should be safe, with a very small race window, if any.
*	__del__(): Only unlock if locked.	bwarsaw	1998-07-22	1	-1/+2
\|
*	Several changes, primarily to make this more robust. So far, no more	bwarsaw	1998-07-22	1	-26/+77
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	locking problems. JV please eyeball... 1. Got rid of is_locked attribute. Test for locking makes an explicit test that a) the tmpfname exists and b) the pid read from the file is our pid. This means that two instances of FileLock in the same process that share the same lockfile will always be locked and unlocked together (probably doesn't occur except in testing). 2. Added an __del__() which unlocks 3. Moved the creation of the basic lockfile to __kickstart() and added a force argument. When force is true (default is false), the lockfile is first removed then recreated. This is only used if the lockfile contains bogus data, such that the winner could not be determined. In that case, the only way to "break" the lock is to recreate a new basic lockfile. This could potentially leave tmpfname turds, but in reality this shouldn't happen very often. 4. Encapsulate reading and writing of the lockfile into __write() and __read(), so that (most importantly) the umask will be set correctly. This should fix most of the permission problems associated with the lockfile by assuring that they are group writable. A side effect: don't eval() the contents of the lockfile. 5. lock(): Use the above changes. Added an assert for what I think is an invariant: that the winner filename better not be equal to self.tmpfname. Moved the timeout check into an else clause of the pid comparison and eliminated the check of hung_timeout > 0 (this is the one I'm least sure about).
*	Fixed indentation (so changes look bigger than they really are).	bwarsaw	1998-07-06	1	-64/+76
\| \| \| \| \| \|	Since there's still problems with locking, I added a little better diagnostic to the one os.unlink() exception I've been getting a lot. This should be removed when fixed.
*	I removed a potential race condition, if two files decide to time-out	viega	1998-06-24	1	-13/+17
\| \| \| \| \| \|	a lock at the same time. This may have been Barry's problem. It should at least fix it (the os.error one), even if I'm not 100% sure of how it is happening.
*	Sometimes I miss type checking... fixed a collision between a method	viega	1998-06-13	1	-6/+7
\| \| \| \|	and a variable.
*	New file locking class that is, in theory, portable. Since this is	viega	1998-06-13	1	-0/+100
	code that could easily be independant of the Mailman library, I use the Python std lib naming conventions of all lowercase method names instead of the mixed-case way in which most of Mailman is done.