Dear God, I HATE man pages....

[rsbriggs]

F_GETLK: Get the first lock that blocks the lock described by the variable of type struct flock pointed to by the third argument, arg, taken as a pointer to type struct flock. The information retrieved overwrites the information passed to fcntl() in the flock structure. If no lock is found that would prevent this lock from being created, the structure is passed back unchanged, except that the lock type is set to F_UNLCK.

:bang: :bang: :bang:

[Bok]

Obvious isn't it........ :lmao: :dunno:

[bwkaz]

You're reading the wrong manpages. :p Take a look at the Linux man-pages project -- it may not provide the best stuff in the world, but at least it's better than what you posted.

For example, my fcntl(2) manpage (which is from the man-pages project) says:


F_GETLK

On input to this call, lock describes a lock we would like to place on the file. If the lock could be placed, fcntl() does not actually place it, but returns F_UNLCK in the l_type field of lock and leaves the other fields of the structure unchanged. If one or more incompatible locks would prevent this lock being placed, then fcntl() returns details about one of these locks in the l_type, l_whence, l_start, and l_len fields of lock and sets l_pid to be the PID of the process holding that lock. Translation:

fcntl() takes a struct flock pointer as its third argument when the second argument is F_GETLK (check lock status), F_SETLK (take or release lock), or F_SETLKW (take or release lock; the W means "if a conflicting lock is held, don't fail the call, but wait until the conflicting lock is released"). The fcntl() call will not actually take any locks when its second argument is F_GETLK; it will only check whether the lock you're describing in the struct flock can be taken.

If the lock can be taken (no conflicting lock is held by any other process at this instant), then fcntl() will set the l_type field of the struct flock to F_UNLCK.

If the lock cannot be taken (because a conflicting lock is held by another process), then the other process's PID, and details about the conflicting lock, are stuffed into the struct flock.

Clear as mud? ;)

Note that you still have to check for errors when you call fcntl() with F_SETLK -- just because the F_GETLK call sets l_type to F_UNLCK, does not mean that a subsequent F_SETLK call must succeed. Another process may have taken a conflicting lock in between the F_GETLK call and the F_SETLK call.

(So why does F_GETLK even exist? Probably so that processes can warn the user that conflicting locks exist, before they try to take them. Presumably the idea is that the process can find out info about the process holding the conflicting lock, tell the user this info, and then the user can kill the other process if needed, before the F_SETLK call. That's just a guess though.)

[Bok]

dear god, this almost makes sense after 5 beers, 5 vodka tonics and a couple of cocktails of which I have no earthly idea what they were called....

Bok

[gopher_yarrowzoo]

Yeah well erm it does, but only after translation into German then Manderin Chinese and back to english... and a few more beers

[rsbriggs]

Actually, what BWKaz posted reads ever-so-much better than the original man page.....

Yeah - I know, just because it's currently lockable doesn't mean that trying to obtain a lock will succeed, because someone else may have snuck in and obtained a lock in the meantime.

Needs an atomic test-and-set, IMHO....

BTW, thanks.......