--- a/ch03.roff	Sun May 06 17:33:45 2012 +0200
+++ b/ch03.roff	Mon May 07 15:50:09 2012 +0200
@@ -109,6 +109,27 @@
 marked legacy in RFC 2822. It was superseded by FIXME.
 Mmh does no more support this header.
 .P
+Native support for `Face' headers
+had been removed, as well.
+The feature is similar to the `X-Face' header in its intent,
+but takes a different approach to store the image.
+Instead of encoding the image data directly into the header,
+the the header contains the hostname and UDP port where the image
+date could be retrieved.
+Neither `X-Face' nor the here described `Face' system
+\**
+.FS
+There is also a newer but different system, invented 2005,
+using `Face' headers.
+It is the successor of `X-Face' providing colored PNG images.
+.FE
+became well used in the large scale.
+It's still possible to use a Face systems,
+although mmh does not provide support for any of the different systems
+anymore. It's fairly easy to write a small shell script to 
+extract the embedded or fetch the external Face data and display the image.
+Own Face headers can be added into the draft template files.
+.P
 `Content-MD5' headers were introduced by RFC\^1864. They provide only
 a verification of data corruption during the transfer. By no means can
 they ensure verbatim end-to-end delivery of the contents. This is clearly
@@ -143,11 +164,55 @@
 and
 .Sn \-kill \fUchr\fP
 to name the characters for command line editing.
-The times when this had been neccessary are long time gone.
+The times when this had been necessary are long time gone.
 Today these things work out-of-the-box, and if not, are configured
 with the standard tool
 .Pn stty .
 
+.U2 "Vfork and Retry Loops
+.P
+MH creates many processes, which is a concequence of the toolchest approach.
+In earlier times
+.Fu fork()
+had been an expensive system call, as the process's whole image needed
+to be duplicated. One common case is replacing the image with
+.Fu exec()
+right after having forked the child process.
+To speed up this case, the
+.Fu vfork()
+system call was invented at Berkeley. It completely omits copying the
+image. If the image gets replaced right afterwards then unnecessary
+work is omited. On old systems this results in large speed ups.
+MH uses
+.Fu vfork()
+whenever possible.
+.P
+Memory management units that support copy-on-write semantics make
+.Fu fork()
+almost as fast as
+.Fu vfork()
+in the cases when they can be exchanged.
+With
+.Fu vfork()
+being more errorprone and hardly faster, it's preferable to simply
+use
+.Fu fork()
+instead.
+.P
+Related to the costs of
+.Fu fork()
+is the probability of its success.
+Today on modern systems, the system call will succeed almost always.
+In the 80s on heavy loaded systems, as they were common at
+universities, this had been different. Thus, many of the
+.Fu fork()
+calls were wrapped into loops to retry to fork several times in
+short intervals, in case of previous failure.
+In mmh, the program aborts at once if the fork failed.
+The user can reexecute the command then. This is expected to be a
+very rare case on modern systems, especially personal ones, which are
+common today.
+
 
 .H1 "Draft and Trash Folders
 .U2 "Draft Folder