170 notably in server start-up. </p> <p>The emulator still runs as a single WIN32 |
170 notably in server start-up. </p> <p>The emulator still runs as a single WIN32 |
171 process, so a Symbian platform process can still accidentally write into the |
171 process, so a Symbian platform process can still accidentally write into the |
172 address space of another Symbian platform process. </p> <p><b>Thread scheduling</b> </p> <p>The emulator uses the same scheduling algorithm |
172 address space of another Symbian platform process. </p> <p><b>Thread scheduling</b> </p> <p>The emulator uses the same scheduling algorithm |
173 as Symbian platform running on hardware. This is in contrast with EKA1 that |
173 as Symbian platform running on hardware. This is in contrast with EKA1 that |
174 leaves Symbian platform thread scheduling to the Windows kernel leading to |
174 leaves Symbian platform thread scheduling to the Windows kernel leading to |
175 discrepancies in behaviour between the emulator and hardware. </p> <p><b>Calling WIN32 APIs from Symbian OS code</b> </p> <p>Because the emulator |
175 discrepancies in behaviour between the emulator and hardware. </p> <p><b>Calling WIN32 APIs from Symbian platform code</b> </p> <p>Because the |
176 now uses the same scheduling algorithm as native Symbian platform, the Symbian |
176 emulator now uses the same scheduling algorithm as native Symbian platform, |
177 platform kernel may have to suspend a thread while it is executing some arbitrary |
177 the Symbian platform kernel may have to suspend a thread while it is executing |
178 code inside Windows. If the thread holds one or more (Windows) locks when |
178 some arbitrary code inside Windows. If the thread holds one or more (Windows) |
179 it is suspended and another thread tries to acquire the same lock(s), a deadlock |
179 locks when it is suspended and another thread tries to acquire the same lock(s), |
180 occurs. To prevent this, Symbian platform code that calls into the WIN32 API |
180 a deadlock occurs. To prevent this, Symbian platform code that calls into |
181 must use new Symbian platform APIs, <codeph>Emulator::Lock()/Unlock()</codeph> or <codeph>Emulator::Escape()/Reenter()</codeph>. |
181 the WIN32 API must use new Symbian platform APIs, <codeph>Emulator::Lock()/Unlock()</codeph> or <codeph>Emulator::Escape()/Reenter()</codeph>. |
182 The impact should be minimal because most of the code interacting with Windows |
182 The impact should be minimal because most of the code interacting with Windows |
183 is in the Base subsystem. </p> </section> |
183 is in the Base subsystem. </p> </section> |
184 <section id="GUID-B3073835-E9D7-5219-BC63-D7296ABB9B5C"><title>Kernel-side |
184 <section id="GUID-B3073835-E9D7-5219-BC63-D7296ABB9B5C"><title>Kernel-side |
185 messages</title> <p>Because the kernel is multi-threaded in EKA2, <xref href="GUID-178E140F-BB15-5A82-99A6-D1BC0E11E018.dita">Kernel-side |
185 messages</title> <p>Because the kernel is multi-threaded in EKA2, <xref href="GUID-178E140F-BB15-5A82-99A6-D1BC0E11E018.dita">Kernel-side |
186 messages</xref> offer a means of communication between Symbian platform threads |
186 messages</xref> offer a means of communication between Symbian platform threads |
300 be updated to use the alternative class. </p> <p>The allocator is created |
300 be updated to use the alternative class. </p> <p>The allocator is created |
301 by the owning thread when it first runs, which means that software that depends |
301 by the owning thread when it first runs, which means that software that depends |
302 on the heap existing before the thread is resumed will no longer work. In |
302 on the heap existing before the thread is resumed will no longer work. In |
303 particular calling <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-6FA3E28C-49D8-39CD-BFC7-FEAEADE40BA5"><apiname>RThread::Heap()</apiname></xref> before the thread runs |
303 particular calling <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-6FA3E28C-49D8-39CD-BFC7-FEAEADE40BA5"><apiname>RThread::Heap()</apiname></xref> before the thread runs |
304 and creates the heap will return NULL. This was a real pattern found in several |
304 and creates the heap will return NULL. This was a real pattern found in several |
305 places in Symbian OS code to work around the lack of processes in the EKA1 |
305 places in Symbian platform code to work around the lack of processes in the |
306 emulator, where a ‘command line’ is inserted into the created thread by allocating |
306 EKA1 emulator, where a ‘command line’ is inserted into the created thread |
307 a cell on the new thread’s heap. This is not an issue for EKA2 as it supports |
307 by allocating a cell on the new thread’s heap. This is not an issue for EKA2 |
308 processes in the emulator and such code should just be removed when adapting |
308 as it supports processes in the emulator and such code should just be removed |
309 it for the EKA2 emulator. </p> </section> |
309 when adapting it for the EKA2 emulator. </p> </section> |
310 </conbody></concept> |
310 </conbody></concept> |