[Mailman-Developers] Subscribers suddenly"disappear"

Mark Sapiro mark at msapiro.net
Fri Aug 22 02:27:19 CEST 2008

Hash: SHA1

Stephen J. Turnbull wrote:
> Mark Sapiro writes:
>  > 1) add_member saves the list with the first member.
>  > 2) VirginRunner gets there first, instantiates and caches the list.
>  >    It then locks the list, processes the welcome and saves and unlocks
>  >    the list.
>  > 3) add_member gets the lock, adds the second member and saves the list.
>  > 4) Virgin runner gets the second welcome. The list is cached, so it
>  >    uses the cached instance. It then locks the list which ultimately
>  >    calls MailList.__load() to refresh the list data, but __load()
>  >    does
>  > 
>  >             mtime = os.path.getmtime(dbfile)
>  >             if mtime <= self.__timestamp:
>  >                 # File is not newer
>  >                 return None, None
> Shouldn't "mtime < self.__timestamp" do the right thing (much more
> often)?

I didn't reply sooner because when I first saw this, I didn't read it
carefully, and I didn't "get" what Stephen was saying. Then I had to
think about it.

I have concluded that barring resetting of clocks backward, "mtime <
self.__timestamp" is equivalent to "False". Whenever a config.pck is
written or read in a process, __timestamp is set to the current mod time
of the config.pck. Thus, the value of self.__timestamp for a cached list
object is always <= mtime.

> You're still vulnerable to "date -s", adjtime, and friends,
> though, and of course you'll have some undesirable cache misses at
> times when it would be nice if you didn't.

Always, I think.

> A better way would be to add a serial number.

As has already been mentioned, it does no good to put a serial number in
the list object since you'd have to read the config.pck to get the
serial number. It would have to be encoded in the file name or stored in
a separate database. Storing it separately adds the complication of an
additional file plus making sure the additional file is sync'd with
config.pck. Encoding it in the file name seems complex as well.

I lean towards the simpler approach of just reading the config.pck every

- --
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

Version: GnuPG v1.4.7 (MingW32)


More information about the Mailman-Developers mailing list