Chapter 1

� The original program consisted of a sequential engine, with perhaps a second thread
being used for interface work. In that case, it is generally more efficient not to create a
CPosixServer and to use STDLIB in 'direct' mode. Indeed, if you introduce several,
separate engines into a program – CODECs for different sound formats, for example –
then you still need not use a CPosixServer object, as the various engines won't be
sharing files.
� If the original engine was designed in a multithreaded manner, then you will almost
certainly have to use a CPosixServer. Remember, though, that you can only share
STDLIB objects, so you're totally dependent on the functionality it provides you.
The background active object processing technique is more memory- efficient, more
predictable, and almost always preferred – assuming you have the choice.
8.2.3 Global Data
As was mentioned earlier, writable global data is not allowed in Symbian OS DLLs. This can
cause problems for ported code. In practice, there are several approaches for dealing with
this, but they involve some rewriting:
� Thread local storage (TLS)
� Explicit This
� Global variables masterclass
Thread local storage
Thread Local Storage is the closest thing there is to global variables in Symbian OS. For
each DLL, it is possible to register a pointer to a dynamically created struct or class
object, and then to look it up whenever it is required. The basis of the technique is that
having done this, all global variables are remapped to data fields within the structure. In fact,
this is on a per thread, per DLL basis, with each thread potentially having its own globals.
(Indeed, this is how the STDLIB implements errno and other global variables so that each
thread has its own errno copy.) If you use multithreading, you will have to be careful about
this.
The generally recommended way of using TLS is to incorporate OpenL() and Close()
functions, and then to call these as the program is created or shut down – typically from the
document or app UI classes' constructors and destructors. The OpenL() and Close()
functions are then responsible for creating and destroying the global object respectively. A
possible implementation is as follows (where Globals is the struct that holds the global
data).
EXPORT_C void MyEngine::OpenL()
{
Globals *globals = STATIC_CAST(Globals*, Dll::Tls());
if(globals == NULL)
{
globals = new(ELeave) Globals;
Mem::FillZ(globals, sizeof(Globals));
Dll::SetTls(globals);
}
globals->_count += 1;
}