Symbian OS Explained - Effective C++ Programming For Smartphones (2005) (779885), страница 37
Текст из файла (страница 37)
Each of theTExcType enumeration values each correspond to one of the categoriesabove but they identify the exception further, for example EExcBoundsCheck, EExcInvalidOpCode and EExcStackFault are all types ofthe KExceptionFault category.What should an exception handler function do? Well, you cannotidentify where the problem occurred from within the handler, so theonly thing you can do is leave from the handler function. Effectively,the handler converts an exception into a leave which can be caughtand dealt with.
However, by doing this, you require a TRAP aroundevery operation that could generate an exception of that type. This couldhave a significant impact in terms of code size and speed (as discussedin Chapter 2) and as a result, while this technique might be useful fordebugging, it is not recommended for code you intend to release.Without a handler specified, the exception terminates the thread witha KERN-EXEC 3 panic if it occurs during a kernel executive call, or aUSER-EXEC 3 panic if it occurs in a non-system call.10.6ProcessesI introduced processes in Chapter 8 and briefly mentioned them inthis chapter when discussing relative thread priorities.
The RProcessclass can be used to get a handle to a running process, in much thesame way as RThread for a running thread. RProcess is defined ine32std.h and a number of the functions look quite similar to those inRThread.6You can use the default constructor to create a handle to the currentprocess, the Create() function to start a new, named process and theOpen() function to open a handle to a process identified by name orprocess identity (TProcessId). The Resume() functions and assortedfunctions to stop the process will also look familiar.
Note that there is noSuspend() function because processes are not scheduled; threads formthe basic unit of execution and run inside the protected address space ofa process.Chapter 13 discusses the difference between the emulator and targethardware in more detail, but one aspect is particularly relevant here. OnWindows, the emulator runs within a single Win32 process, EPOC.exe,and each Symbian OS process runs as a separate thread inside it.6The SDK documentation for RThread and RProcess is extensive and should beconsulted for further details of both these classes. Like the RThread class, RProcess hasbeen secured in EKA2, resulting in the removal of some functions and the restriction ofothers to apply only to the currently running processPROCESSES165On EKA1 the emulation of processes on Windows is incomplete andRProcess::Create() returns KErrNotFound.
To emulate any codethat spawns a separate process, e.g. server startup code, different sourcecode is required for emulator builds, using threads instead of processesin which to launch the server. The EKA2 release has removed thisinconvenience. While Symbian OS still runs in a single process onWindows (indeed, that’s what the ”S” in WINS, WINSCW and WINSBstands for), the emulation is enhanced and you can use the same code,calling RProcess::Create() on both platforms.
Symbian OS, foremulator builds, translates this call to creation of a new Win32 threadwithin EPOC.exe.I’ll conclude this chapter with a brief description of the most fundamental process within Symbian OS, the kernel server process, and the threadswhich run within it. I’ll restrict the discussion to Symbian OS EKA1 – youwill be able to find more detail of the changes introduced by EKA2 from therelevant system documentation (www.symbian.com/technology/product descriptions.html).
On EKA1, the kernel server process is aspecial process that contains two threads which run at supervisor privilege level:• the kernel server threadThis is the first thread to run in the system and has the highestpriority of all threads. It implements all kernel functions requiringallocation or deallocation on the kernel heap and manages hardwareresources. Device drivers run in the kernel thread and use interruptservice routines and delayed function calls to service events fromthe hardware.• the ”Null” or ”Idle” threadThis has the lowest priority in the system and therefore runs whenno other threads are ready to run. It switches the processor into idlemode to save power, by calling a callback function to shut down partof the hardware. This allows Symbian OS to conserve power mostefficiently, thus maximizing the battery life. To allow the Null threadto run, your code should wait on events (typically using active objectsor kernel signaling primitives such as mutexes) rather than pollingconstantly.
A polling thread prevents the Null thread from runningand stops Symbian OS from entering its idle, power-saving, mode.The other threads in the system are known as user threads and run in anunprivileged state. User threads can access kernel services, such as otherthreads or processes, using the APIs in the user library (EUser.dll).When a user thread requires a kernel service, EUser either switches tothe kernel executive, which runs kernel-privileged code in the contextof the running thread, or makes a call via the executive into the kernelserver process.16610.7SYMBIAN OS THREADS AND PROCESSESSummaryThis chapter compared the use of pre-emptively scheduled threads onSymbian OS with cooperatively scheduled active objects.
Active objectsare preferred for most multitasking code because they have lower runtimeoverheads. However, threads are sometimes necessary, for example ifpriority-based pre-emption is required or to perform a long-runningbackground task asynchronously where it cannot be split into increments.The chapter reviewed the RThread class, which represents a handleto a thread on Symbian OS. It identified the differences in the RThreadAPI between EKA1 and EKA2 releases, because EKA2 has removed thefacility for one thread to affect any other thread running in a separateprocess. The RThread API allows a thread handle to rename a thread,modify its priority and suspend, terminate or panic it.
It also provides ameans by which data may be transferred between threads (inter-threaddata transfer is discussed in more detail in Chapters 11 and 12).The chapter concluded by discussing Symbian OS processes in brief,and included a short description of the threads running with the EKA1kernel server process.The use of active objects for multitasking on Symbian OS is discussedin Chapters 8 and 9.11The Client–Server Frameworkin TheoryIn theory there is no difference between theory and practice. Inpractice there isYogi BerraThis chapter examines the client–server framework model on SymbianOS. I’ll be discussing the theory, such as why client–server is used onSymbian OS, how it works and the implementation classes involved.There’s a lot of information, so I’ll use a question and answer structure tobreak the chapter down clearly into logical sections.When programming for Symbian OS, it is likely that you will oftenuse system servers transparently, via classes that wrap the actual detailsof client–server communication.
It’s less common to implement yourown server or write client-side code that accesses a server directly. Soin this chapter, I’ll make it clear which information you can skip if youreally only want to know the basics of the Symbian OS client–serverarchitecture and how to use a server as a typical client.
I’ll illustrate thechapter with examples of how to use a typical Symbian OS system server,the file server.The next chapter works through some example code for a SymbianOS client and server, to illustrate how a typical implementation is puttogether and explain how to go about writing your own.This chapter discusses the client–server model for Symbian OS releasesup to and including v7.0s (the code samples use the client–server APIsfrom Symbian OS v7.0). On Symbian OS v8.0, the concepts are generallythe same, but some of the APIs have changed. Rather than confuse matters,I’ve decided to concentrate solely on the releases available at the timeof going to press.
You can find more information about the differencesin v8.0 from the relevant v8.0 SDKs when they become available, fromother Symbian press books and, I hope, later editions of this book, orfrom the Symbian website (www.symbian.com/technology.html).16811.1THE CLIENT–SERVER FRAMEWORK IN THEORYWhy Have a Client–Server Framework?A client makes use of services provided by a server. The server receivesrequest messages from its clients and handles them, either synchronouslyor asynchronously.1 Data is passed from the client to the server in therequest message itself or by passing a pointer to a descriptor in theclient address space, which the server accesses using kernel-mediateddata transfer.On Symbian OS, servers are typically used to manage shared accessto system resources and services.
The use of a server is efficient since itcan service multiple client sessions and can be accessed concurrently byclients running in separate threads.A server also protects the integrity of the system because it can ensurethat resources are shared properly between clients, and that all clientsuse the resources correctly. When the server runs in its own processit has a separate, isolated address space and the only access a clienthas to the services in question is through a well-defined interface. Byemploying a server in a separate process, the system can guaranteethat misbehaved clients cannot corrupt any of the resources the servermanages on its behalf or for other clients.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
