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 state 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 the DB Interface Module is based on the polling paradigm. To determine asynchronous call completion, the DB Interface Module 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 the ready state, accessing the object will potentially block except for the following two functions:
bool
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
RWDBStatus Behavior in the Asynchronous Context .
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. When the object that made the asynchronous call goes out of scope, any pending asynchronous operation from that object will cause the application thread to block until the asynchronous operation has completed.
Note that the previous explanation uses
RWDBResult only as an example. The discussion holds good for all the objects returned by asynchronous invocations of the functions listed in
Asynchronous Calls in the DB Interface Module.
