Symbian Learning Notes (6)--About multiple threads and active objects

Symbian supports multithreading (it has a rthread class) but does not advocate the use of multiple threads, because it is generally said that the application is more secure? But I think the most persuasive thing is to save electricity.

In that case, let's not say "multithreading", say "multitasking", the active object (active object) provides a non preemptive multitasking mechanism that is not multithreaded but runs in a single thread.

The AO mechanism consists of two classes of Cactivescheduler and cactive:

Scheduler Cactivescheduler: As the name suggests, it is the dispatcher who coordinates multiple active objects. Since it is not preemptive, then what is its scheduling principle? The textbook says:

(A) Checks all active objects that have been registered, based on the order of precedence of the active object.

B to determine whether it is active (isactive) and whether its istatus is not krequestpending.

C) The Runl method to execute it is satisfied.

Active Object cactive: This can be understood as a "thread", just like the runable in Java. It is subject to the command of the dispatcher, and its key is the Istatus member variable of type Trequeststatus.

In general, there will be an asynchronous operation in Cactive (the method parameter list includes a treuqeststatus type argument), and if not, it doesn't matter (depending on the scheduling principle above, just make sure it's not krequestpending).

Because the GUI application comes with Cactivescheduler, the thing we do is implement a subclass of Cactive, overload method Runl (), Docancel (), and Runerror (). Of course there should be a method like start to start it.

Start is responsible for starting, typically to perform an asynchronous operation (such as loading a JPEG image, as in the previous article, or to open a timer, as in the case of a book). If you don't have an asynchronous operation, you can do nothing here. But in any case, its last line must be setactive (), making itself active.

RUNL is responsible for the specific work, if the start of an asynchronous operation, this should be handled after the end of the transaction (such as the image loaded in the previous article can be displayed on the screen). If you didn't start an asynchronous operation just now, you have to do something.

There is a situation in which we have a big task broken into a number of small tasks, put in the RUNL to do, then we have to add a state tint istate to record this callback should do which step small task (each completes a small task to change a istate value, and also have to setactive, Keep the active object active until all tasks are complete.

Docancel provides the means by which users can abort an active task, while Runerror provides an opportunity for error handling.

In addition, in this cactive subclass, there should be a place (typically in constructl) to put itself in the queue of the scheduler, that is, call Cactivescheduler::add (this).

A piece of code, that is, the previous code to load the JPEG image should be placed in an AO to implement, using the wizard to generate a cactive subclass:

class CImageLoader : public CActive
...{
public:
~CImageLoader();

// Two-phased constructor.
static CImageLoader* NewL(CDemoUIAppView *p);
static CImageLoader* NewLC(CDemoUIAppView *p);

public: // New functions
void StartL( );

private:
CImageLoader();
void ConstructL();

private: // From CActive
void RunL();
void DoCancel();
TInt RunError( TInt aError );
private:
RFs iRFs;
CDemoUIAppView *iParent;
CImageDecoder *iDec;
};