file locking primitive
David T. Lewis
lewis at mail.msen.com
Sat Jan 3 20:06:05 UTC 2004
On Sat, Jan 03, 2004 at 06:43:16PM +0100, David Gorisek wrote:
> Regarding file locking primitives, there is also another issue that has
> to be taken into account.
> On Unix when the same process locks the same file region twice, the
> second call will succeed.
> On Windows the second call will fail, becuase the file region is already
> For true interoperability the file locking behavior should be the same
> across various OSs.
> OmniBase expects that file locking behavior is the same as on Windows.
> Therefore for Unix systems OmniBase currently implements its own
> internal file locking table so that locking behavior of the
> ODBFileStream is the same as on Windows.
Another platform-specific issue would be how to handle mandatory
versus advisory locking. Win32 implements what would be called
"mandatory locking" on a Unix system. This means that, for example,
a file write would fail if it was accessing a locked region, whereas
advisory locking requires that the region be explicitly tested for
a lock prior to doing the write. Unix can do both kinds of locking,
but requires special mounting of the file system for mandatory locks,
so this is not practical in the general case.
I suppose that both mandatory and advisory locking could be
implemented, but that would probably lead to a lot of conditional
code in applications. So it really should come down to the expected
uses. If users of file locking are likely to also be able to control
how the file systems are mounted (as might be the case for a database
server application), then Win32 style mandatory locking would make
sense. If locking is going to be used by ordinary Squeak users for
mail clients, then the advisory locking approach would be the lowest
The above is just based on my reading of the various man pages and
MSDN, not actual experience, so don't assume I know what I'm talking
More information about the Squeak-dev