CS_NETIO determines whether a connection is synchronous, fully asynchronous, or deferred-asynchronous:
On a synchronous connection, a routine that requires a server response blocks until the response is received.
On a fully asynchronous connection, a routine that requires a server response returns CS_PENDING immediately. When the response arrives and the routine completes its work, Client-Library automatically calls the connection’s completion callback.
Depending on the host platform, the completion callback is invoked either at the system interrupt level (on platforms that use signal-driven network I/O) or from a Client-Library runtime thread (on platforms that use thread-driven network I/O). For a description of the network I/O method used for your platform, see the Open Client and Open Server Programmers Supplement for Microsoft Windows and the Open Client and Open Server Programmers Supplement for UNIX.
On a deferred-asynchronous connection, a routine that requires a server response returns CS_PENDING immediately. The connection must call ct_poll to find out if the routine has completed. If the application has installed a completion callback and a routine has completed, ct_poll invokes the completion callback before returning.
On platforms that do not support multithreading or signal-driven network I/O, such as Microsoft Windows 98, connections can only be synchronous or deferred-asynchronous. Even if the CS_NETIO property is set to CS_ASYNC_IO, the connection is deferred-asynchronous, and the application must poll for completions with ct_poll.
WARNING! In an Open Sever gateway application, the CS_NETIO property cannot be set to CS_ASYNC_IO. The Open Server thread scheduler provides multitasking in an Open Server application.
An application can set up deferred asynchronous connections only at the context level, by calling ct_config with *buffer as CS_DEFER_IO. CS_DEFER_IO is not a legal value at the connection level.
Asynchronous connections use the type of asynchronous I/O that matches their parent context. For example, suppose an application sets up deferred-asynchronous connections at the context level and then creates a synchronous connection within the context. If the application later calls ct_con_props with *buffer as CS_ASYNC_IO to make this connection asynchronous, the connection will be deferred-asynchronous, not fully asynchronous.
A context can include both synchronous and asynchronous connections, but the asynchronous connections within a context must all be fully asynchronous or must all be deferred-asynchronous.
The following restrictions apply to an application’s use of CS_NETIO:
An application cannot set CS_NETIO for a context if the context has open connections.
An application cannot set CS_NETIO for a connection if the connection has any active commands or pending results.
For more information about asynchronous Client-Library programming, see “Asynchronous programming”.
