http://bugzilla.spamassassin.org/show_bug.cgi?id=3442
------- Additional Comments From [EMAIL PROTECTED] 2004-05-31 16:10 -------
> > So if unlink kills the lock, why not do lock(), then unlink() in proc A?
>
> in thinking about this some more, I'm thinking the answer is: to do the lock
> the
> process creates the file, then sits on flock(). therefore, doing the unlink
> won't work since the file will go away, and other processes will have issues?
Yes; other procs would wind up creating and locking an entirely different
lock file -- each proc would have their own lockfile. Hence no different
from _not locking at all_. ;)
> I really would like to change this so the lock file doesn't need to be kept
> around all the time, but I'm also thinking this would be ok for a 3.1 release
> since it's too complex for now.
>
> For 3.0, I'd be happy with a doco change making it clear that this behavior
> will
> occur if you use flock locking.
Here's an alternative; if you can be sure the DB file will *not* change
inode number while it's open, we could lock on that file, like so:
1. open < db_file
2. lock that fd
3. DB_File::open()
4. ...
5. DB_File::close()
6. unlock fd
7. close fd
We cannot just use the DB_File::fd() call, as that won't work (see DB_File
manual page).
To be honest, I think leaving a .lock file around is better than that, since
that hack requires that the DB module not do things like change the inode
number of the db file on disk, which is just too much for us to assume IMO.
Here's a better alternative; don't call the lock file ".lock"; call it
".sync", ".ctrl", or something else.
Would that help? After all, the problem is that it's too much like the
.lock filename we use for NFS-safe locking, but the semantics are totally
different.
--j.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
