CS_MEM_POOL identifies a pool of memory that Client-Library uses to satisfy its memory requirements.
Ordinarily, Client-Library routines satisfy their memory requirements by calling malloc. However, not all implementations of malloc are reentrant, so it is not safe to use malloc in Client-Library routines that are called at the system interrupt level. For this reason, on systems where Client-Library uses signal-driven network I/O, such as UNIX systems, fully asynchronous applications are required to provide an alternate way for Client-Library to satisfy its memory needs. This is not a requirement on platforms that use thread-driven network I/O or for applications that do not use fully asynchronous connections. The Open Client and Open Server Programmer’s Supplement describes the network I/O method used on your platform.
Client-Library provides two mechanisms by which an asynchronous application satisfy Client-Library’s memory needs:
The application uses the CS_MEM_POOL property to provide Client-Library with a memory pool.
The application uses the CS_USER_ALLOC and CS_USER_FREE properties to install memory allocation routines that Client-Library safely calls at the operating system interrupt level.
If a fully asynchronous application fails to provide Client-Library with a safe way to satisfy memory needs, Client-Library’s behavior is undefined.
ct_config returns CS_FAIL if an application attempts to set a memory pool that does not meet Client-Library’s minimum pool size requirements.
On UNIX systems, a memory pool should include approximately 6K for each connection.
Client-Library attempts to satisfy memory requirements from the following sources, in the following order:
Memory pool
User-supplied allocation and free routines
System routines
If a connection cannot get the memory it needs, Client-Library marks the connection dead.
An application is responsible for allocating and freeing the memory identified by CS_MEM_POOL.
An application can replace a memory pool by calling ct_config with action as CS_SET and buffer as the address of the new pool.
An application clears a memory pool in two ways:
By calling ct_config with action as CS_SET and buffer as NULL
By calling ct_config with action as CS_CLEAR
An application cannot set or clear a memory pool for a context in which CS_CONNECTION structures currently exist. A context must drop all CS_CONNECTION structures before clearing a memory pool.
