locked record

[Kenneth Brody]

On 1/5/2015 11:36 PM, Fairlight wrote:
> http://0pointer.de/blog/projects/locking.html
>
> Pretty sure filePro uses fcntl() for record locking.  I know of no other
> byte-range locking mechanism.  Which explains -much-, actually, if you read
> the article.

Well, lockf() is available, but it's just a wrapper for fcntl() on many systems.

[...]
> The whole problem with finding out what has a -record- lock -is- precisely
> because it's bound to a process, not to a file descriptor.  Which means you
> must go through every last process on the system (or on all systems in the
> case of networked clients) and look at the locks they hold - if that's even
> possible, as opposed to just looking at the file.

On *nix, showlock can "see" the current locks on a file (via fcntl), and the 
info includes the PID of the owner.  No need to query every process to see 
if they have any locks for the given file.  (Technically, for the inode.)

> Also, pretty sure this breakdown of fcntl() describes exactly why filePro
> will fail to have a record locked after -one- file descriptor to an open
> file is closed, even if others are open; it's apparently never been
> filePro's fault, but rather POSIX fcntl() file locking's fault, since
> there's zero notification to other lock-holders.  I've always thought
> that was filePro's fault for not tracking enough of its own locking.  But
> assuming I'm right about it using fcntl(), it appears to be entirely
> unavoidable.  My long-overdue apologies to Ken, if my new conclusion is
> correct.

If you have multiple lookups to a file, filePro only has the file opened 
once.  All lookups share the same file handles.


Of course, the OP was talking about Windows, making the above meaningless in 
that context, as there is no call that I am aware of equivalent to the POSIX 
fcntl(F_GETLK) call, which will return info about existing locks by other 
processes.

-- 
Kenneth Brody