Wiley.Symbian.OS.Internals.Real.time.Kernel.Programming.Dec.2005.eBook-DDU (779891), страница 23
Текст из файла (страница 23)
You should also beware of creatinga higher-priority thread than this one. If you delay the nanokernel timerDFC by more than 16 nanokernel timer ticks, you run the risk of adverselyaffecting the accuracy of the nanokernel timers.3.3.9.5 The timer threadThis thread has priority 27. It manages the Symbian OS timer queues.The timer thread is also available for device drivers to use if they needit – the function Kern::TimerDfcQ() returns a pointer to the DFCqueue serviced by this thread.3.3.10 Threads – conclusionIn this section I’ve discussed both nanothreads and Symbian OS threads.I’ll now go on to describe a Symbian OS object that has no nanokernelequivalent – the process.WHAT IS A PROCESS?933.4 What is a process?Under Symbian OS, a process is both a single instantiation of an executable image file and a collection of one or more threads that share aparticular address space (or memory mapping).
This address space may,or may not, be different to that of other processes in the system – thisdepends on whether the processor in the mobile phone has an MMU, andon which particular memory model the phone manufacturer has chosento use.In most cases, designers will want to ensure that they protect processesfrom each other by choosing the memory model appropriately.
In thiscase, a thread in one process will not be able to directly access thememory belonging to a thread in another process – although, it will ofcourse be able to directly access the memory of any thread in the sameprocess. So you can see that, with the appropriate choice of memorymodel, the process is the fundamental unit of memory protection underSymbian OS.The loader creates a process by first asking the kernel to create aDProcess object, then loading the image and informing the kernel thatit has done so. The kernel creates a single thread, marks it as the mainthread, and starts execution at the process’s entry point. The main threadis marked as KThreadFlagProcessPermanent (see Section 3.3.8),but the application can change this later.As well as sharing an address space, the threads in a process areconnected in other ways:• You can specify their priorities relative to the process priority; changingthe process priority will change the priorities of all such threads.
(Youmay also specify absolute thread priorities – these do not changewhen the process priority is changed)• If the process exits or is terminated, then the kernel terminates all thethreads in the process with the same exit information• Threads in the same process can share object handles; this is notpossible for threads in different processes• A user thread can create a new thread only in its own process.This section is quite a lot shorter than the one on threads, since the twothings that are mainly of interest for processes are how they are loaded,which I will cover in Chapter 10, The Loader, and the role they play inaddress spaces, which I will cover in Chapter 7, Memory Models. Allthat remains is to discuss the Symbian OS representation of the process,DProcess.94THREADS, PROCESSES AND LIBRARIES3.5 DProcess classLike many other classes in the kernel, this class is derived from DObject,which makes it a dynamically allocated reference counted object.
DProcess is the kernel object referred to by a user-side RProcess handle.Here a cut-down version of the class:class DProcess : public DObject{public:DProcess();∼DProcess();TInt Create(TBool aKernelProcess, TProcessCreateInfo& aInfo,HBuf* aCommandLine);TInt SetPriority(TProcessPriority aPriority);TInt Logon(TRequestStatus* aStatus, TBool aRendezvous);void Rendezvous(TInt aReason);TInt AddCodeSeg(DCodeSeg* aSeg, DLibrary* aLib, SDblQue& aQ);TInt RemoveCodeSeg(DCodeSeg* aCodeSeg, SDblQue* aQ);TBool HasCapabilityNoDiagnostic(TCapability aCapability);private:virtual TInt NewChunk(DChunk*& aChunk, SChunkCreateInfo& aInfo,TLinAddr& aRunAddr)=0;virtual TInt AddChunk(DChunk* aChunk,TBool isReadOnly)=0;virtual TInt DoCreate(TBool aKernelProcess,TProcessCreateInfo& aInfo)=0;virtual TInt Loaded(TProcessCreateInfo& aInfo);public:TInt NewThread(DThread*& aThread, SThreadCreateInfo& aInfo,TInt* aHandle, TOwnerType aType);virtual void Resume();void Die(TExitType aType,TInt aReason,const TDesC &aCategory);public:TInt iPriority;SDblQue iThreadQ;TUint8 iExitType;TUint8 iPad1;TUint8 iPad2;TUint8 iPad3;TInt iExitReason;TBufC<KMaxExitCategoryName> iExitCategory;DObjectIx* iHandles;TUidType iUids;TInt iGeneration;TUint iId;TUint32 iFlags;HBuf* iCommandLine;DProcess* iOwningProcess;SDblQue iTargetLogons;RArray<SCodeSegEntry> iDynamicCode;SSecurityInfo iS;SSecurityInfo iCreatorInfo;TUint iCreatorId;TUint iSecurityZone;TInt iEnvironmentData[KArgIndex];public:enum TProcessAttributes {DPROCESS CLASS95EPrivate=2,ESupervisor=0x80000000,EBeingLoaded=0x08000000,EResumed=0x00010000 };TInt iAttributes;TLinAddr iDataBssRunAddress;DChunk* iDataBssStackChunk;DCodeSeg* iCodeSeg;DCodeSeg* iTempCodeSeg;DMutex* iProcessLock;DMutex* iDllLock; // can be held while in user mode// user address to jump to for new threads, exceptionsTLinAddr iReentryPoint;};Key member data of DProcessiThreadQDoubly linked list of all threads belonging to this process.
Accesses tothis list are protected by the process lock mutex.iHandlesPointer to array (DObjectIx) of process-global handles for this process.iDataBssStackChunkPointer to chunk-holding process global data (.data and .bss sections)and, in most cases, user stacks of threads belonging to this process. Thememory model determines whether or not user stacks are placed in thischunk.iDataBssRunAddressRun address of base of initialized data.iDynamicCodeRArray listing all explicitly dynamically loaded code segments whichare attached to this process – that is, only ones corresponding to DLLswhich have been explicitly loaded, not the process EXE code segment(iCodeSeg) or code segments which are attached to the process onlydue to implicit linkages from other code segments.
For each such codesegment this array contains two pointers – a pointer to the DCodeSegobject and a pointer to the DLibrary or (for the kernel process only)the DLogicalDevice DPhysicalDevice object that represents theprocess’s use of the code segment.iCodeSegPointer to DCodeSeg object that represents the executable image usedto create this process. This value is set when the process is fully loadedand ready to be resumed.iTempCodeSegTemporary pointer to DCodeSeg object that represents the executableimage used to create this process. This value is only used during process96THREADS, PROCESSES AND LIBRARIEScreation; it is set to NULL when the process is fully loaded and ready tobe resumed.iAttributesProcess attributes.
Some of these are generic (private, supervisor, beingloaded, resumed); the memory model defines some more.iFlagsProcess flags (just-in-time debug).iProcessLockPointer to DMutex object used to protect the process thread list and insome memory models, the process address space list.iDllLockPointer to DMutex object used to protect DLL static data constructorsand destructors that run user-side in this process. Note that this mutex isheld while running user-mode code and hence the thread need not entera critical section before acquiring it; these are the only mutexes used bythe kernel with this property.3.5.1 Processes in the emulatorThe increased code-sharing in the EKA2 emulator means that the EKA2emulator provides much better emulation of Symbian OS processes thanthe EKA1 emulator did.
The emulator can instantiate a process froma .EXE file and has the same object and thread ownership model as ontarget hardware. The EKA1 emulator failed to emulate processes at all.That said, debugging multiple processes on a host OS is difficult andso the EKA2 emulator still executes as a single process in the host OS.Indeed, the emulator does not provide a complete emulation of processesas found on target platforms. In particular, the following aspects ofprocesses are not completely emulated:1.Memory protection between processes, or between user and kernelmode2.Full support for multiple instances of a DLL with writable static data.The EKA1 emulator shares both these failings.3.5.1.1 When a .EXE is not an EXEUnder Windows, a process is instantiated from a Portable Executable (PE)format file of type EXE. However, a process instantiated in this way maynot load and link further EXE files.
This means that the emulator must usea PE file of type DLL to create a new emulated Symbian OS process.DPROCESS CLASS97The Symbian tool chain could build all EXE targets for the emulatoras host DLLs. These would then be easily loaded into the emulator asan emulated process. Unfortunately this prevents the EXE from beinginvoked from the Windows command line, something which has proveduseful with EKA1. It also makes it impossible to load multiple instancesof a process that has static data, because static data support is providedby the host OS, and the emulator is a single process in the host OS.We solved this dilemma by making certain assumptions about the PEfile format and the Windows platform:1.
The difference between a DLL and an EXE is a single bit in the PEfile header2. Identical copies of a DLL with different file names load as independentmodules in the host OS.This is currently true for all the Win32 platforms we have tested.When creating a process within the emulator, we go through thefollowing steps:1. We copy the EXE file to a new filename2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
