Preprocessor macro expanding to a command
Space | User/kernel |
Context | Sync/async |
May block | No |
SPL | Any |
Dynamic memory | No |
#include <SPAD/AC.H>
CALL_IORQ_LSTAT(iorq, handler);
This is a preprocessor macro that expands to machine- and compiler-dependent code to call an IORQ. Its functionality is similar to CALL_IORQ, except that it expects that the IORQ status was already initialized and leaves it untouched.
fn
pointing to AST function declared with DECL_AST. The status field of this structure must have been already initialized with CALL_IORQ, CALL_IORQ_CANCELABLE, RETURN_IORQ or RETURN_IORQ_CANCELABLE. IORQs on the same SPL are called in the same order they were queued, but the programmer must not depend on it for correctness. The programmer may depend on this feature for good performance (for example networking packets are queued with this call — the protocols are required to handle out-of-order packets correctly, altough it causes performance degradation).
DECL_IOCALL(FUNCTION2, SPL_DEV, IORQ)DECL_IOCALL(FUNCTION, SPL_DEV, IORQ)
{
  some code...
  CALL_IORQ_LSTAT(RQ, FUNCTION2);
  RETURN;
}
...
In this example, FUNCTION
passes its IORQ to FUNCTION2
. IORQ was already initialized when the caller posted it to FUNCTION
.
If there were CALL_IORQ, the code would be buggy with respect to canceling an IO request. If cancel was attempted after entry to FUNCTION
but before CALL_IORQ
, CALL_IORQ
would erase the cancel status and the cancel request would be missed. CALL_IORQ_LSTAT
doesn't change status — so the cancel status will be pending until FUNCTION2
either returns the request immediatelly or attempt to add it to a wait queue (at which point it discovers the pending cancel and returns -EINTR
instead of queueing it).