Chapter 4 57
Programming Guide
4. Using Synchronous vs. Asynchronous Mode
If ap_rcv() is called in asynchronous mode, data is read from the
communication endpoint until either:
• the entire primitive is received
• the ubuf argument buffer is full
• no more user data is available.
In the second case, the AP_MORE bit is set in the flags parameter of
ap_rcv(). If the AP_MORE bit is set, a primitive was partially received.
To receive the rest of the primitive, the ap_rcv() must be re-invoked until
the call returns successfully.
In the third case:
• Either ap_rcv() returns successfully with the AP_MORE bit set and
ubuf is partially filled. In this case, to use the remaining ubuf space
for the next ap_rcv() you must re-adjust ubuf->len.
• Or, ap_rcv() returns unsuccessfully with ap_errno set to AP_AGAIN.
In this case, you must not alter any parameters for the next ap_rcv().
Refer to the discussion in the ap_rcv() manpage for more information.
Check the sptype after each ap_rcv() call. Some primitives such as
A_ABORT_IND are not flow-controlled and may interrupt the receipt of
a partially received primitive. In this case, the remaining data of the
original primitive is lost.
Note that ap_rcv() may still be blocked by running in asynchronous mode
in memory shortage situations such as when using large numbers of
connections.
Changing Modes
Once a communication endpoint has been opened using synchronous
mode, it can be changed to asynchronous mode in the application by
setting the AP_STREAM_FLAGS attribute with AP_NDELEY.
However, to reset the execution to synchronous mode, the communication
endpoint must be closed and reopened without using O_NDELEY in the
ap_open() call.
To Next Page
Loading...
Need help?
General