Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A version of this page is also available for
4/8/2010

Most of the LDAP function calls have both asynchronous and synchronous versions. A synchronous function call, identified by an _s suffix in the function name, must return before the client can continue executing code. Synchronous functions return LDAP_SUCCESS if successful or another LDAP error code if the call failed.

When you make an asynchronous function call, the client can continue with other tasks, including making new requests to the server or processing the results of a search, while the asynchronous request is in progress. Most asynchronous functions return a message identifier for each operation.

At any time a client application can check on the status of an asynchronous call by calling ldap_resultwith the message identifier. To abandon an asynchronous call in progress, call ldap_abandon.

Because the function returns a message identifier, rather than a return code, these asynchronous functions are not thread-safe. To determine whether the call returned an error value, you have to retrieve the return code from the connection block. It is possible for another thread to overwrite the return code before you retrieve it. The extended operation calls provided with LDAP 3.0, identified by an _ext suffix, are thread-safe because they pass the message identifier back to the caller as an out parameter.

See Also