Symbian3/SDK/Source/GUID-AF07AD54-86F1-5DB7-80FF-633A559DA4BD.dita
changeset 2 ebc84c812384
parent 0 89d6a7a84779
--- a/Symbian3/SDK/Source/GUID-AF07AD54-86F1-5DB7-80FF-633A559DA4BD.dita	Fri Jan 22 18:26:19 2010 +0000
+++ b/Symbian3/SDK/Source/GUID-AF07AD54-86F1-5DB7-80FF-633A559DA4BD.dita	Thu Mar 11 15:24:26 2010 +0000
@@ -29,10 +29,10 @@
 <li><p><xref href="GUID-545DA961-217E-49CA-A90E-7A41E2C03A99.dita">Forking without <codeph>exec()</codeph></xref></p></li>
 <li><p><xref href="GUID-B58D282E-E6EC-4AE1-96DB-30A5FB850563.dita"><codeph>exec()</codeph> without
 forking using <apiname>posix_spawn()</apiname></xref></p></li>
-</ul> <p><b>Omission of fork()</b> </p> <p>A Unix-like kernel
-is designed with the two stage process creation in mind. On Symbian platform
-(and Microsoft Windows®) the kernel was designed to create a process, which
-runs a single executable, in a single step. </p> <p>P.I.P.S. does not implement
+</ul> <p><b>Omission of fork()</b> </p> <p>A Unix-like kernel is designed
+with the two stage process creation in mind. On the Symbian platform (and
+Microsoft Windows®), the kernel was designed to create a process, which runs
+a single executable, in a single step. </p> <p>P.I.P.S. does not implement
 the <codeph>fork()</codeph> operation because this would require an entirely
 new way of dealing with processes in the kernel and memory model. For example,
 duplicating the address space of an existing process was not something that
@@ -44,13 +44,13 @@
 the standard way to load a process image into memory. Only the initialisation
 process is loaded directly into a new address space (special case code in
 the kernel), all other processes are loaded into an existing address space
-which was initially created by forking. </p> <p>On Symbian platform, the only
-way to load a process image into memory is using the loader. It assumes that
-the image is being loaded as a new process - one that owns no resources, has
-no open handles and so on. The change to the loader and any associated kernel
-changes, to support the <codeph>exec()</codeph> function were deemed to be
-too risky. </p> <p><b>Generic IPC</b> </p> <p>P.I.P.S. supports two types
-of Inter-Process Communication (IPC) between processes or threads: </p> <ul>
+which was initially created by forking. </p> <p>On the Symbian
+platform, the only way to load a process image into memory is using the loader.
+It assumes that the image is being loaded as a new process - one that owns
+no resources, has no open handles and so on. The change to the loader and
+any associated kernel changes, to support the <codeph>exec()</codeph> function
+were deemed to be too risky. </p> <p><b>Generic IPC</b> </p> <p>P.I.P.S. supports
+two types of Inter-Process Communication (IPC) between processes or threads: </p> <ul>
 <li><p> <b>Pipes (named and unnamed):</b> Unnamed pipes are created using <xref href="GUID-EC7F85FF-FD4E-324C-8D01-EF6F7E7A79FE.dita"><apiname>pipe()</apiname></xref> and
 named pipes are created using <xref href="GUID-F4749DAA-1B29-3D1D-A3AA-0D52B851E501.dita"><apiname>mkfifo()</apiname></xref>. Pipe-based communication
 is also possible between a parent and a child process when the child is created