Chapter 1

You can use AOs for background processing. Consider the following code sequence, which
can be called from inside an AO:
TRequestStatus* status = &iStatus;
User::RequestComplete(status, KErrNone);
SetActive();
This construct bypasses the idea of a system call indicating completion of an asynchronous
event – it's saying, 'Run me as soon as possible.' Using this sequence, you can get a very
similar effect to using threads.
Using this technique will involve some rewriting; for instance, your engine may need to
become an active object, and you may need an observer class that tells the main application
that the background processing has finished.
Note
One possible problem with converting to the AO/AS scheme is if you want to
wait for input on sockets, the console, or similar. If you use synchronous
calls, which wait until any input is available, then these will block the whole
thread – remember that you can only switch to another active object when
you exit the current RunL()call. With C++ library calls, the solution would be
to use the asynchronous version of the library call, but at face value there
are no asynchronous implementations within STDLIB. To help with this,
there are overloaded versions of the ioctl() call with an extra
TRequestStatus& parameter. These can be used in a variation on a
select() call, where you can be told when data is available on a single file
descriptor, or when data has been written. For more information, see the
STDLIB documentation and the header file estlib.h.
CPosixServer
STDLIB runs quite differently depending on whether a CPosixServer object exists or not. If
you need one of these, it must be created before you start to use STDLIB, or the system will
get confused. If it exists, then all file and socket operations are redirected to the thread that
owns the CPosixServer object. Because all files are owned by a single thread, Symbian
OS is quite happy with this arrangement – indeed, it is essentially oblivious to the fact, as all
it sees is the interthread communication. To create the CPosixServer object, you should
use InstallPosixServerActiveObject( ) or SpawnPosixServerThread() – the
latter creates a special thread for the server object, and is probably preferred. Once created,
the server object is largely invisible to the program and works behind the scenes. On the
other hand, if STDLIB is used without a CPosixServer object having been created, then all
resources are owned by the thread that opened the file, socket, and so on, and cannot be
accessed by other threads.
There are disadvantages with using the POSIX server. Firstly, it adds an additional clientserver
transaction each time you access a shared resource and secondly, this approach only
applies to STDLIB function calls; you will need to do some extra work if your ported code
calls back to C++ code.
The standard recommendation is that you always try to rewrite a thread-based program
using the active object technique. Because active objects are non-preemptive, there are no
problems with mutual exclusion, and no problems with objects being shared. However,
removal of threads completely is not always so simple.
In practice, you will encounter two situations: