Date: Fri, 30 Nov 2001 13:40:46 -0600
From: John Wade <[EMAIL PROTECTED]>
Organization: Oakton Community College
CC: "Scot W. Hetzel" <[EMAIL PROTECTED]>,
Heiki Kask <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
[...]
[... cyrus locks a file it already has locked ...]
seen_lockread() can be called multiple times without relocking the
file. It calls "DB->fetchlock()" which, given an already started
transaction, doesn't bother relocking the file but instead does a
binary search on the already open & mmap'd file.
I don't believe that Cyrus will ever attempt to call lock_reopen() on
a file it already holds a lock on.
[...]
I am not sure if locking the file multiple times by the same process
can be considered a bug or not, but it may be that this is not the
normal way that flock is used and it is possible that the linux kernel
has not been tested extensively in this way. I am curious if all of
the other folks with this problem are using linux or if it also shows
up in solaris and other Unix flavors.
It's not necessarily a bug in a Unix program, but I believe Cyrus's
locking conventions should never attempt to do this.
I also have some confusion about how the seen system is supposed to
work. The model cyrus uses seems to be:
Read the file and cache it in a buffer to speed up subsequent
accesses.
mmap() the file, really. possibly lock the file so that no one
else attempts to write during a RMW cycle.
When you want to write the file, lock it, write out the new file as
filename.NEW, lock the new file, and rename the new back to the
original name (replacing the original) Then unlock
correct.
Subsequent reads always check to see if the file has been replaced
and if it has, read in the new file, otherwise use the cached buffer
version for performance reasons.
re mmap() the file, that's correct.
Larry
