Table of Contents
provides
for control over descriptors. The argument is a descriptor to be operated
on by as follows: Return a new descriptor as follows: Lowest numbered
available descriptor greater than or equal to Same object references
as the original descriptor. New descriptor shares the same file offset
if the object was a file. Same access mode (read, write or read/write).
Same file status flags (i.e., both file descriptors share the same file
status flags). The close-on-exec flag associated with the new file descriptor
is set to remain open across system calls. Get the close-on-exec flag associated
with the file descriptor If the low-order bit of the returned value is
0, the file will remain open across otherwise the file will be closed
upon execution of is ignored). Set the close-on-exec flag associated with
to the low order bit of (0 or 1 as above). Get descriptor status flags,
as described below is ignored). Set descriptor status flags to Get the
process ID or process group currently receiving and signals; process
groups are returned as negative values is ignored). Set the process or
process group to receive and signals; process groups are specified by
supplying as negative, otherwise is interpreted as a process ID. The
flags for the and flags are as follows: Non-blocking I/O; if no data
is available to a call, or if a operation would block, the read or write
call returns -1 with the error Force each write to append at the end of
file; corresponds to the flag of Enable the signal to be sent to the
process group when I/O is possible, e.g., upon availability of data to be
read. Several commands are available for doing advisory file locking;
they all operate on the following structure: struct flock { off_t l_start; /*
starting offset */
off_t l_len; /* len = 0 means until end of file */
pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write, etc. */
short l_whence; /* type of l_start */
}; The commands available for advisory record locking are as follows:
Get the first lock that blocks the lock description pointed to by the
third argument, taken as a pointer to a (see above). The information retrieved
overwrites the information passed to in the structure. If no lock is found
that would prevent this lock from being created, the structure is left
unchanged by this function call except for the lock type which is set to
Set or clear a file segment lock according to the lock description pointed
to by the third argument, taken as a pointer to a (see above). is used
to establish shared (or read) locks or exclusive (or write) locks, as
well as remove either type of lock If a shared or exclusive lock cannot
be set, returns immediately with This command is the same as except
that if a shared or exclusive lock is blocked by other locks, the process
waits until the request can be satisfied. If a signal that is to be caught
is received while is waiting for a region, the will be interrupted if
the signal handler has not specified the (see When a shared lock has
been set on a segment of a file, other processes can set shared locks on
that segment or a portion of it. A shared lock prevents any other process
from setting an exclusive lock on any portion of the protected area. A request
for a shared lock fails if the file descriptor was not opened with read
access. An exclusive lock prevents any other process from setting a shared
lock or an exclusive lock on any portion of the protected area. A request
for an exclusive lock fails if the file was not opened with write access.
The value of is or to indicate that the relative offset, bytes, will
be measured from the start of the file, current position, or end of the
file, respectively. The value of is the number of consecutive bytes to
be locked. If is negative, the result is undefined. The field is only used
with to return the process ID of the process holding a blocking lock. After
a successful request, the value of is Locks may start and extend beyond
the current end of a file, but may not start or extend before the beginning
of the file. A lock is set to extend to the largest possible value of the
file offset for that file if is set to zero. If and point to the beginning
of the file, and is zero, the entire file is locked. If an application
wishes only to do entire file locking, the system call is much more efficient.
There is at most one type of lock set for each byte in the file. Before
a successful return from an or an request when the calling process has
previously existing locks on bytes in the region specified by the request,
the previous lock type for each byte in the specified region is replaced
by the new lock type. As specified above under the descriptions of shared
locks and exclusive locks, an or an request fails or blocks respectively
when another process has existing locks on bytes in the specified region
and the type of any of those locks conflicts with the type specified in
the request. This interface follows the completely stupid semantics of
System V and that require that all locks associated with a file for a
given process are removed when any file descriptor for that file is closed
by that process. This semantic means that applications must be aware of
any files that a subroutine library may access. For example if an application
for updating the password file locks the password file database while making
the update, and then calls to retrieve a record, the lock will be lost
because opens, reads, and closes the password database. The database close
will release all locks that the process has associated with the database,
even if the library routine never requested a lock on the database. Another
minor semantic problem with this interface is that locks are not inherited
by a child process created using the function. The interface has much
more rational last close semantics and allows locks to be inherited by
child processes. is recommended for applications that want to ensure the
integrity of their locks when using library routines or wish to pass locks
to their children. Note that and locks may be safely used concurrently.
All locks associated with a file for a given process are removed when
the process terminates. A potential for deadlock occurs if a process controlling
a locked region is put to sleep by attempting to lock the locked region
of another process. This implementation detects that sleeping until a locked
region is unlocked would cause a deadlock and fails with an error.
Upon successful completion, the value returned depends on as follows:
A new file descriptor. Value of flag (only the low-order bit is defined).
Value of flags. Value of file descriptor owner. Value other than -1. Otherwise,
a value of -1 is returned and is set to indicate the error.
will
fail if: The argument is the type of lock is a shared lock or exclusive
lock and the segment of a file to be locked is already exclusive-locked
by another process; or the type is an exclusive lock and some portion of
the segment of a file to be locked is already shared-locked or exclusive-locked
by another process. is not a valid open file descriptor. The argument
is or the type of lock is a shared lock and is not a valid file descriptor
open for reading. The argument is or the type of lock is an exclusive
lock and is not a valid file descriptor open for writing. is and the
maximum allowed number of file descriptors are currently open. The argument
is and a deadlock condition was detected. The argument is and the function
was interrupted by a signal. is and is negative or greater than the
maximum allowable number (see The argument is or and the data to
which points is not valid, or refers to a file that does not support
locking. The argument is and the maximum number of file descriptors permitted
for the process are already in use, or no file descriptors greater than
or equal to are available. The argument is or and satisfying the lock
or unlock request would result in the number of locked regions in the system
exceeding a system-imposed limit. is and the process ID given as argument
is not in use.
The function call appeared in
Table of Contents