Java Reference
In-Depth Information
First, queue the asynchronous operation and let the Java thread on
which the operation is invoked go to sleep:
synchronized (this)
{
// queue the async operation
iError = _callSomeAsyncOperation(iNativePeerHandle);
if(iError == NO_ERROR)
{
try
{
// put the current Java thread to sleep until operation finishes
iError = PENDING;
wait(MAX_TIMEOUT);
}
catch (InterruptedException ex1)
{
}
}
}
if (iError == NO_ERROR)
{
... // async operation completed. continue normal flow
}
else
{
... // async operation failed. handle error
}
Secondly, the native asynchronous operation is performed on a native
JES thread. (This involves a large amount of code so we do not provide
example code.)
Thirdly, when the operation is complete, the Java notification thread
invokes a method in the Java object to pass the response data and wakes
up the sleeping Java thread:
public void notifyBlockingOperationCompleted(int aError)
{
synchronized (this)
{
iError = aError;
notify();
}
}
After
notify()
is invoked, the sleeping Java thread wakes up and
continues execution from the line next to the call to
wait()
, to handle
the operation completion. You probably noticed that there is some
magic which triggers
notifyBlockingOperationCompleted()
to
be called. How does the Java notification thread knowwhen the operation
is complete?
Under the hood, upon completion of the asynchronous operation, the
JES puts a Java stack frame on the notification thread stack and wakes up
the notification thread (all that is done in native code with direct access
to the Java thread stack). When the notification thread wakes up, the first
thing it does is the next operation in its stack, which was queued by the JES.
In the layout of the run-time stack of the CLDC-HI HotSpot VM, there
are three basic forms of stack frame that are constructed on the Java
