10.3 Handling Asynchronous Call Completions

To determine the completion of an asynchronous call, the caller can query the non-blocking isReady() function of the returned object. Most of the other functions of the object potentially block until the object becomes ready. The ready status signals completion of the asynchronous call. Note that the change of state of the returned object from notReady to ready occurs if and only if the caller tries to access the future object. This is because the asynchronous support provided by DBTools.h++ is based on the polling paradigm. To determine asynchronous call completion, DBTools.h++ polls the underlying database vendor's API using the application thread; it doesn't spawn its own thread.

If the returned object is not in ready state, accessing the object will potentially block except for the following two functions:

RWBoolean
RWDBResult::isReady()

This call will not block. Since this function checks the underlying API for asynchronous call completions, accessing this function can speed up the completion of an asynchronous call.

RWDBStatus
RWDBResult::status()

This call will not block. However, accessing the returned RWDBStatus will behave as described in Section 10.4.

All the other functions of a future object potentially block if it is not in a ready state. A blocked application thread is not necessarily put to sleep; it may be used to constantly check the underlying API for asynchronous call completion.

Note that the above explanation uses RWDBResult only as an example. The discussion holds good for all the objects returned by asynchronous invocations of the functions listed in Section 10.7.