|
|
Many Transport Interface library routines may block waiting for an incoming event or the relaxation of flow control. However, some time-critical applications should not block for any reason. Similarly, an application may wish to do local processing while waiting for some asynchronous transport interface event.
Support for asynchronous processing of Transport Interface events is available to applications using a combination of the STREAMS asynchronous features and the non-blocking mode of the Transport Interface library routines. The example server code in ``Data transfer'' illustrated the use of the I_SETSIG ioctl command for processing events asynchronously. The poll system call may also be used for this purpose.
In addition, each Transport Interface routine that may block waiting for some event can be run in a special non-blocking mode. For example, t_listen will normally block, waiting for a connect indication. However, a server can periodically poll a transport endpoint for existing connect indications by calling t_listen in the non-blocking (or asynchronous) mode. The asynchronous mode is enabled by setting O_NDELAY or O_NONBLOCK on the file descriptor. These can be set as a flag on t_open, or by calling fcntl(2) before calling the Transport Interface routine. fcntl can be used to enable or disable this mode at any time. All programming examples in this section use the default synchronous processing mode.
O_NDELAY or O_NONBLOCK affect each Transport Interface routine differently. To determine the exact semantics of O_NDELAY or O_NONBLOCK for a particular routine, see the relevant pages.