Help: using msvcrt for file locking

[Sheila King]

On Tue, 28 Aug 2001 01:20:42 GMT, bokr at accessone.com (Bengt Richter)
wrote in comp.lang.python in article
<3b8ac249.624843477 at wa.news.verio.net>:

:On Mon, 27 Aug 2001 06:14:56 GMT, Sheila King <sheila at spamcop.net> wrote:
:[...]
:>
:>Actually, I think what happens with Windows98, is that there is only
:>exclusive lock. No shared locking (which is what one would want for
:>reading). So, I could change the name of the file when a write process
:>wants to acquire it. Otherwise, if the un-renamed file is there, it is
:>OK to read from it. Do you think this type of approach would work for
:>the reading part only? 
:>
:Yes, but there's a problem, because you need to be able to distinguish
:2+n states of a file: (1) not open for anything (2) open for readonly
:n>0 times (3) open for exclusive writing.

Yes, I had been thinking about this last night and the good part of this
morning, and hadn't come up with a solution, yet. However, thanks to
David Bolen's suggestion, I think I won't have to handle it this way,
after all.
...<snippage>>..
:A writer has to be able watch for the count of readers to go to zero
:one way or another. Perhaps you could have readers create individual
:expiring read-lock files named by appending their os.pid() numbers
:plus time tag to the name of the file to lock. Then the writer could
:watch for all those to disappear or expire.

Right. It would be tricky to code. I had not thought of a good way, yet.

:This only applies for high traffic on win32, but since on win32 the
:writer can't assume ability to rename as a mechanism for preventing
:additional readers when the file is already open (it get permission
:denied, unlike unix), perhaps if the writer process creates its own
:write-lock file as a first step, then potential readers could defer
:creating their read-lock files if they see that, and existing ones
:would cycle out or expire, and the writer could  rename and open the file.
:
:For unix the write-lock file would be a waste, since renaming will succeed
:unless the file is in orphan form. And unless you are fighting a humongous
:swarm of readers all interested in one file on win32, it shouldn't hurt
:to leave it out there either.

This is very useful and interesting information for me. I did play a bit
and discover that I could not rename open files on win32, but I could on
Linux. So, I can see that there is quite a bit of difference between how
the file systems work.

:Note that the atomicity of renaming is critical to making this work. E.g.,

Would someone please explain the concept of "atomic" or "atomicity" with
respect to file operations. Do you mean, that you are (below) showing in
detail, step-by-step what would happen at each point in the process that
you suggest?

:reader        writer
:--------    ------------
:[ck wlock]      .           <-not really needed except high traffic win32?
:   .         [set wlock]    <-ditto
:   .         rename         <-not safe to eliminate
:   .         ck rlocks
:   .         open for w
:set rlock       .
:open for r      .
:   .         write
:read ??
:
...<other good info snipped>...
:
:On win32 the rename would raise an exception if the reader had succeeded,
:so the rlock check could effectively be accomplished just with that, but
:as mentioned, that's not true on unix, so it needs to be in the waiting
:loop for win32 with a try/except wrapper, and the rename should not
:be repeated if it succeeds, as it normally will on unix.
:
:It'd be nice if the builtin open had an option for exclusive access within
:a specified timeout for trying ;-)

Actually, the win32file.CreateFile does have an option for exclusive
access. I don't believe there is a specified timeout, but it does have
the exclusive access part.

Thanks again for all these tips and info. It really helps.

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/