Java Reference
In-Depth Information
the value is returned synchronously. On the other hand, reading bytes
from a TCP connection requires the use of asynchronous methods in the
native Symbian ESock C++ API. Queuing of the asynchronous operation
follows a similar route but the actual reading from the TCP connection is
performed on a separate native thread.
10.6 Handling Asynchronous Symbian OS Operations
The handling of asynchronous operations is a major mechanism intrinsic
to the Java ME subsystem. Just as a KJNI interface was defined to decouple
libraries from a VM implementation, a similar argument holds for the
handling of asynchronous events and operations, which is clearly VM-
dependent, for example, whether the VM supports lightweight threads
or not. An abstraction was needed to ensure that all libraries operate
independently of the VM implementation.
Asynchronous operations and events in Symbian OS make use of
the asynchronous active object idiom, which is inherent to Symbian
OS design. The challenge is that handling asynchronous operations
is not guaranteed to be identical or portable between different VM
implementations. For example, the CLDC-HI HotSpot runs on a single
primordial native thread on which all native operations must complete
synchronously and never block. So again, a generic VM-agnostic solution
was developed - Java Event Server (JES). A JES provides a native thread
that can run an active scheduler and offers an inter-thread communication
mechanism to simplify interaction between the main thread and the JES
thread. There are multiple JES instances running, but the mechanism as
a whole operates as if there is a single Java Event Server. That solves
the first issue, in which all operations must complete synchronously and
never block - the only operation done on the VM thread is to queue a
request for the asynchronous operation that is executed later, on the JES
thread. Then come two other challenges: the Java operation might be
synchronous; and there is a need to report the response back to Java code
when the asynchronous operation is complete.
Dealing with the first challenge is fairly straightforward. The request
for the native asynchronous operation is queued on the native VM thread
and returns immediately. When the call returns to Java, the current Java
thread is put to sleep. Who wakes it up and when brings us to the
second challenge - reporting the response back to the Java code when
the asynchronous operation is complete.
For the second challenge, another VM-agnostic solution was de-
signed. The idea is that the MIDP run-time environment has an inter-
nal Java thread which carries notification about the completion of an
asynchronous operation. Let's see an example of how this is done in
code.
