Chapter 1

A RunL() function can stop the active scheduler by issuing
CActiveScheduler::Stop(). When that RunL() returns, the function call to
CActiveScheduler::Start() will complete.
Stopping the active scheduler will bring down the thread's event- handling framework, which
is not something you should do lightly. Only do it if you are the main active object that
controls the thread.
As a server programmer, you have to provide server bootstrap code that includes creating
and starting the active scheduler for your server thread. I'll show you how to do that in
Chapter 19.
The active scheduler offers a nesting facility, whereby you can issue
CActiveScheduler::Start() from within a RunL() function. This is used to keep the
active scheduler going while ostensibly handling a synchronous function. The end of the
'synchronous' function is indicated by a matching CActiveScheduler::Stop(). The net
effect is like Yield() in some systems. This method is used by modal Uikon dialogs.
You shouldn't nest the active scheduler however, unless you have thought carefully through
the implications of doing so. In particular, you must ensure strict nesting of all
CActiveScheduler::Start() and CActiveScheduler::Stop() functions – which is
of course a natural property of modal dialogs.
17.2.5 Adding Functionality to the Active Scheduler
CActiveScheduler is a concrete class that can be used as is. It also provides two virtual
functions that can be used if you need them for additional purposes:
� If a RunL() called by the active scheduler leaves and that leave is not handled by the
active object's RunError(), then Error(TInt) is called with the leave code. By
default, this function panics.
� WaitForAnyRequest() may be used to perform some standard processing before
issuing User::WaitForAnyRequest(). By default, this function simply issues
User::WaitForAnyRequest() and any override must also ensure that it calls
User::WaitForAnyRequest().
The Uikon environment sets up an active scheduler whose Error()function displays a
natural-language version of the KErrXxx error code with which RunL() left.
The CONE environment overrides CActiveScheduler::WaitForAnyRequest() to
ensure that the window server's client-side buffer is flushed before issuing
User::WaitForAnyRequest(). That means that any drawing done by the client during a
RunL() is sent to the window server for execution so that while waiting for the next user
input, there is no outstanding drawing.
If you're implementing a server, it's useful to implement a scheduler with its own Error()
function. We'll show how to do this in the GDSP server implementation, in Chapter 19.
Don't write over-elaborate overrides for CActiveScheduler::Error() and
CActiveScheduler::WaitForAnyRequest(). If they're too elaborate, you create
dependencies between your active objects and your active scheduler, which means that
your active objects won't run in any other environment than (say) the server for which you
designed them. That might be fine – just make sure you've thought about it.