User guide

8: Client Applications — DLI Overview
DC 900-1338I 151
8.1.2 Blocking versus Non-blocking I/O
Note
Earlier Simpact releases used the term “synchronous” for blocking
I/O and “asynchronous” for non-blocking I/O. Some parameter
names reflect the previous terminology.
Non-blocking I/O applications are useful when doing I/O to multiple channels with a
single process where it is not possible to “block” (sleep) on any one channel waiting for
I/O completion. Blocking I/O applications are useful when it is reasonable to have the
calling process wait for I/O completion.
In the Freeway environment, the term blocking I/O indicates that the
dlOpen, dlClose,
dlRead and dlWrite functions do not return until the I/O is complete. For non-blocking
I/O, these functions might return after the I/O has been queued at the client, but before
the transfer to the ICP is complete. The client must handle I/O completions at the soft-
ware interrupt level in the completion handler established by the
dlInit or dlOpen func-
tion, or by periodic use of
dlPoll to determine the I/O completion status.
The
asyncIO DLI configuration parameter specifies whether an application session uses
blocking or non-blocking I/O (set
asyncIO to “no” to use blocking I/O). The alwaysQIO
DLI configuration parameter further qualifies the operation of non-blocking I/O activ-
ity. Refer to the Freeway Data Link Interface Reference Guide for more information.
The effects on different DLI functions, resulting from the choice of blocking or non-
blocking I/O, are explained in the Freeway Data Link Interface Reference Guide.
Server-resident applications must use non-blocking I/O; support for blocking I/O in
server-resident applications is not available.