User`s guide

3: Programming Using the DLITE Embedded Interface
DC 900-1516D 39
vious writes are not posted as complete until DLI receives this LocalAck, then the
LocalAck is thrown away). However, the DLITE user is responsible for receiving each
LocalAck and performing any necessary processing. The DLITE behavior is exactly the
same as when the DLI
LocalAck configuration parameter is set to “no”. This generally
implies the client application should post a
dlRead after each dlWrite to receive the
expected Local Ack.
3.3.1.3 AlwaysQIO Support
DLI optionally supported an “AlwaysQIO” feature (applicable only when using
non-blocking I/O), which restricted notification of completed I/O to callback invoca-
tions only. If an I/O completed immediately in the I/O request, the completion would
not be reported with the return of the
dlRead or dlWrite request. Instead, notification
would be through the user-supplied callback.
DLITE always behaves as if the
AlwaysQIO configuration parameter is set to “yes” (non-
blocking I/O only). Non-blocking I/O should always return with
EWOULDBLOCK
while the I/O completes.
3.3.1.4 Changes in Global Variable Support
DLI maintained three global variables; dlerrno, iICPStatus, and cfgerrno. The global vari-
ables
iICPStatus and cfgerrno are not supported for DLITE. The iICPStatus value simply
returned the value contained in the ICP status field, which is now available to the
DLITE application in the
iICPStatus field from the OptArgs. The information in cfgerrno
is no longer available.
The
dlerrno variable is still available, but has been redefined for DLITE as a function call
returning an integer (
int _dlerrno()). Reference to dlerrno becomes a function call which
returns the last error. Note that this definition precludes using
dlerrno as an “L-value” in
a “C” expression.