Always living in the synchronization process is undoubtedly one of the greatest expectations of the coders. In order not to block the UI, In order to read and write a Tuo data, in order to carry out complicated logic with painstaking efforts, and to work together in harmony, asynchronous processing is always required. Let's take a look at it and complete the task together. In Symbian, a mechanism is implemented to do this, which is active objects. Active objectsactive object is an event-driven multitasking model. In the standard Symbian thread (remove some java constructor threads, native C constructor threads, and so on), there is a message loop, in the loop, the trequeststatus status of each activeobject in the cactivescheduler of the thread is continuously queried. Once an executable task is found, it is immediately activated and executed. The classic cyclic pseudo code is as follows:
// *** In the loop ***
User: waitforanyrequest ();
forever
{< br> If (activeobject-> isactive () & activeobject-> istatus! = Krequestpending)
{< br> activeobject-> iactive = efalse;
trapd (R, activeobject-> runl ();
If (R! = Kerrnone)
{< br> r = activeobject-> runerror ();
If (R! = Kerrnone)
error (r);
}< br> break;
}< BR >}
A thousand words. In the message loop, the system waits for the event to be activated, and then traverses the status of registering each active object. Of course, simple traversal is not decent enough. Every active object comes with a priority. Without a doubt, execution with a higher priority will be prioritized, and a lower priority will never surpass. By default, everyone uses eprioritystandard. If an active object needs to be executed for a long time, you can consider using low priority, epriorityidle, and eprioritylow. This will reduce the execution frequency. If a task has some real-time requirements, a high priority is required, for example, epriorityuserinput and epriorityhigh. However, this model is insufficient to meet real-time requirements because it is non-preemptible. A low-priority task has been scheduled, where it is not enough for you to have a higher priority. In this mode, self-discipline is required to maintain a good response capability. First, if a task has a high real-time performance, you need to increase the priority of its execution thread or process so that it is scheduled by the CPU preferentially, without the opportunity to execute a low-priority task. Also, do not place the execution efficiency in the runl of the active object. Code (If the thread is not the main thread, it will take a look...), it will make the thread lose the ability to respond to other requests. Each asynchronous task needs to be derived from the cactive class. If you use the system wizard, you can find that Symbian wants each cactive subclass to do the following:
- implement runl and place the Execution Code waiting for the callback party.
- implement the docancel method to properly place tasks that have no chance of reaching the destination. This is a template method mode, it will be placed in cancel and called only when the status is executed;
- after an error is executed, the cactive subclass is given a self-Salvation opportunity;
- try to tell the user that there is no free lunch in the world. You need to use setactive to send the request to the executor, let it help you solve the problem.
The core of task-driven control is trequeststatus. After receiving the task, the executor sets trequeststatus to krequestpending. When this status is changed again, the execution callback of cactivescheduler is triggered. Shows the entire process (still stolen...): the client-server framework is an important mechanism of Symbian. In the Symbian kernel layer, this mode is widely used to strip file management, interface management, and other functions into various services, showing a microkernel situation. The so-called client-server framework is the function caller client, and the function executor server, each of which is in a different thread or process. They are built on active objects and are usually called in asynchronous mode. However, the client-server does not impose any constraints on the execution mode. For example, the file service has two call modes: synchronous and asynchronous, synchronization is implemented only by blocking Asynchronization. Client-server is divided into two types: Same process and cross-process. Needless to say, the communication mode is completely different. In cross-process mode, a session needs to be established between the client and the server to communicate. Session is the encapsulation of Symbian IPC and communicates with each other in Protocol mode. In the same process, it is much easier to transmit information. In many cases, it is better to use a pointer. In the cross-process mode, it is suitable for centralized control and unified resource management. It is especially suitable for file services. The same process is suitable for big data transmission and logic operations. Each thread runs its own logic. Compared with synchronization, Asynchronization is no doubt cruel, but with these frameworks, it is much more fun to have a thread and communicate with others. Symbian has something that can be found. It is really not easy *_*.
