korry wrote: > > The Win32 API for locking seems mighty strange to me. > > Linux/Unix byte locking is advisory (meaning that one lock can block > another lock, but it can't block a read). No -- it is advisory meaning that a process that does not try to acquire the lock is not locked out.
Right, that's why I said "can block" instead of "will block". An advisory lock will only block another locker, not another reader (except in Win32).
You can certainly block a file in exclusive mode, using the LOCK_EX flag. (And at least on my Linux system, there is mandatory locking too, using the fcntl() interface).
My fault - I'm not really talking about "file locking", I'm talking about byte-range locking (via lockf() and family).
I don't believe that you can use byte-range locking to block read-access to a file, you can only use byte-range locking to block other locks.
A simple exclusive lock on the first byte past the end of the file will do.
I think the next question is -- how would the lock interface be used? We could acquire an exclusive lock on postmaster start (to make sure no backend is running), then reduce it to a shared lock. Every backend would inherit the shared lock. But the lock exchange is not guaranteed to be atomic so a new postmaster could start just after we acquire the lock and acquire the shared lock. It'd need to be complemented with another lock.
You never need to reduce it to a shared lock. On postmaster startup, try to lock the sentinel byte (one byte past the end-of-file). If you can lock it, you know that no other postmaster has that byte locked. If you can't lock it, another postmaster is running. It is an atomic operation.
However, Tom may be correct about NFS locking, but I guess I'm surprised that anyone would care :-)
> Win32 locking is mandatory (at least in the most portable form) so a > lock blocks a reader. There is also shared/exclusive locking of a file on Win32.
Yes, but Win32 shared locking only works on NTFS-type file systems. And you don't need shared locking anyway.
-- Korry
