> (note that F_GETLK man page does not provide EAGAIN as a
> possible error code).
Hmm....
In the Single UNIX spec, there appears to be a rather unexpected
difference between expected behaviour for lockf and fcntl here:
http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=lockf
[EACCES] or [EAGAIN]
The function argument is F_TLOCK or F_TEST and the section is already
locked by another process.
OTOH
http://www.db.opengroup.org/cgi-bin/dbcgi?CALLER=sud2/indx.tpl&TOKEN=FIYR&TPL=sd_fileframe&dir=xsh&file=fcntl
[EACCES] or [EAGAIN]
The cmd argument is F_SETLK, and one of the following conditions
is true:
* The type of lock (l_type) is shared ( F_RDLCK) or exclusive
( F_WRLCK), and the segment of a file to be locked is
already exclusive locked by another process.
* The type of lock is exclusive, and some portion of the file
segment to be locked is already shared locked or exclusive
locked by another process.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/