Strengthen warning about using lock()

This commit is contained in:
Andrew M. Kuchling 2007-01-24 20:06:41 +00:00
parent 4b884a5cc2
commit 391e917b1a
1 changed files with 12 additions and 8 deletions

View File

@ -58,14 +58,18 @@ skipped, though using a key from an iterator may result in a
\exception{KeyError} exception if the corresponding message is subsequently \exception{KeyError} exception if the corresponding message is subsequently
removed. removed.
Be very cautious when modifying mailboxes that might also be changed \begin{notice}[warning]
by some other process. The safest mailbox format to use for such Be very cautious when modifying mailboxes that might be
tasks is Maildir; try to avoid using single-file formats such as mbox simultaneously changed by some other process. The safest mailbox
for concurrent writing. If you're modifying a mailbox, no matter what format to use for such tasks is Maildir; try to avoid using
the format, you must lock it by calling the \method{lock()} and single-file formats such as mbox for concurrent writing. If you're
\method{unlock()} methods before making any changes. Failing to lock modifying a mailbox, you
the mailbox runs the risk of losing data if some other process makes \emph{must} lock it by calling the \method{lock()} and
changes to the mailbox while your Python code is running. \method{unlock()} methods \emph{before} reading any messages in the file
or making any changes by adding or deleting a message. Failing to
lock the mailbox runs the risk of losing messages or corrupting the entire
mailbox.
\end{notice}
\class{Mailbox} instances have the following methods: \class{Mailbox} instances have the following methods: