NLM_LOCK_MSG - Lock Message
-
-
struct nlm_lockargs {
netobj cookie;
bool block; /* Flag to indicate blocking behaviour. */
bool exclusive; /* If exclusive access is required. */
struct nlm_lock alock; /* Actual lock data */
bool reclaim; /* used for recovering locks */
int state; /* specify local NSM state */
};
None. Results are returned asynchronously via the NLM_LOCK_RES procedure.
-
-
void
NLM_LOCK_MSG(nlm_lockargs) = 7;
This procedure is one of the asynchronous RPCs. It performs the same function as the NLM_LOCK procedure.
This procedure attempts to establish a monitored lock described in "alock".
If "block" is true, and the lock request cannot be granted immediately, the server will return an NLM_LOCK_RES procedure with a status of "LCK_BLOCKED".
When the request can be granted the server will make a call-back to the client with an NLM_GRANTED_MSG procedure. If "block" is set to false, and the lock cannot be granted immediately, the server will return an NLM_LOCK_RES procedure with a status of "LCK_DENIED", and no NLM_GRANTED_MSG call-back will be made. If "reclaim" is true, then the server will assume this is a request to re-establish a previous lock (for example, after the server has crashed and rebooted). During the grace period, the server will only accept locks with "reclaim" set to true.
"state" contains the state of the client's NSM. This information is kept by the server implementation, so if the client crashes, the server can determine which locks to discard by checking this state against the state in the crash notification (SM_NOTIFY) sent by the NSM. See
File Locking over XNFS .
The following sequence occurs if the lock request is blocked:
- Client Server NLM_LOCK_MSG ---> <--- NLM_LOCK_RES (stat is set to LCK_BLOCKED) when the lock can be granted <--- NLM_GRANTED_MSG NLM_GRANTED_RES --->
Contents | Next section | Index |