>> The python I use (win32 2.6.2) does not complain if it cannot read >> from or write to a .pyc; and thus it handles multiple python processes >> trying to create .pyc files at the same time. Is the .zip case really >> any different?
[ snip discussion of difficulty of writing a sharing-safe update ] On Mon, Feb 1, 2010 at 2:28 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: > So what would you do for concurrent writers, then? The current > implementation relies on creat(O_EXCL) to be atomic, so a second > writer would just fail. This is but the only IO operation that is > guaranteed to be atomic (along with mkdir(2)), so reusing the current > approach doesn't work. Sorry, I'm guilty of having assumed that the POSIX API has an operation analogous to win32 CreateFile(GENERIC_WRITE, 0 /* ie, "FILE_SHARE_NONE"*/). If shared-reader/single-writer semantics are not available, the only other possibility I can think of is to avoid opening the .pyc for write. To write a .pyc one would read it, write and flush updates to a temp file, and rename(). This isn't atomic, but given the invariant that the .pyc always contains consistent data, the new file will also only contain consistent data. Races manifest as updates getting lost. One obvious drawback is that the the .pyc inode would change on every update. paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
