#include <sys/types.h> #include <sys/ksynch.h> #include <sys/ddi.h>
bool_t SLEEP_LOCK_SIG(sleep_t *lockp, int priority);
SLEEP_LOCK_SIG may be interrupted by a signal, in which case it may return early without acquiring the lock.
If the function is interrupted by a job control stop signal (e.g. SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) which results in the caller entering a stopped state, the SLEEP_LOCK_SIG function will transparently retry the lock operation upon continuing (the call will not return without the lock).
If the function is interrupted by a signal other than a job control stop signal, or by a job control stop signal that does not result in the caller stopping (because the signal has a non-default disposition), the SLEEP_LOCK_SIG call will return early without acquiring the lock.
Drivers may use these values to request a priority appropriate to a given type of device or to request a priority that is high, medium or low relative to other activities within the kernel.
It is also permissible to specify positive or negative offsets from the values defined above. Positive offsets result in more favorable priority. The maximum allowable offset in all cases is 3 (that is, pridisk+3 and pridisk-3 are valid values but pridisk+4 and pridisk-4 are not valid). Offsets can be useful in defining the relative importance of different locks or resources that may be held by a given driver. In general, a higher relative priority should be used when the caller is attempting to acquire a highly contended lock or resource, or when the caller is already holding one or more locks or kernel resources upon entry to SLEEP_LOCK_SIG.
The exact semantic of the priority argument is specific to the scheduling class of the caller, and some scheduling classes may choose to ignore the argument for the purposes of assigning a scheduling priority.
``Sleep locks'' in HDK Technical Reference