1.1 --- a/ch03.roff	Sun May 06 17:33:45 2012 +0200
     1.2 +++ b/ch03.roff	Mon May 07 15:50:09 2012 +0200
     1.3 @@ -109,6 +109,27 @@
     1.4  marked legacy in RFC 2822. It was superseded by FIXME.
     1.5  Mmh does no more support this header.
     1.6  .P
     1.7 +Native support for `Face' headers
     1.8 +had been removed, as well.
     1.9 +The feature is similar to the `X-Face' header in its intent,
    1.10 +but takes a different approach to store the image.
    1.11 +Instead of encoding the image data directly into the header,
    1.12 +the the header contains the hostname and UDP port where the image
    1.13 +date could be retrieved.
    1.14 +Neither `X-Face' nor the here described `Face' system
    1.15 +\**
    1.16 +.FS
    1.17 +There is also a newer but different system, invented 2005,
    1.18 +using `Face' headers.
    1.19 +It is the successor of `X-Face' providing colored PNG images.
    1.20 +.FE
    1.21 +became well used in the large scale.
    1.22 +It's still possible to use a Face systems,
    1.23 +although mmh does not provide support for any of the different systems
    1.24 +anymore. It's fairly easy to write a small shell script to 
    1.25 +extract the embedded or fetch the external Face data and display the image.
    1.26 +Own Face headers can be added into the draft template files.
    1.27 +.P
    1.28  `Content-MD5' headers were introduced by RFC\^1864. They provide only
    1.29  a verification of data corruption during the transfer. By no means can
    1.30  they ensure verbatim end-to-end delivery of the contents. This is clearly
    1.31 @@ -143,11 +164,55 @@
    1.32  and
    1.33  .Sn \-kill \fUchr\fP
    1.34  to name the characters for command line editing.
    1.35 -The times when this had been neccessary are long time gone.
    1.36 +The times when this had been necessary are long time gone.
    1.37  Today these things work out-of-the-box, and if not, are configured
    1.38  with the standard tool
    1.39  .Pn stty .
    1.40  
    1.41 +.U2 "Vfork and Retry Loops
    1.42 +.P
    1.43 +MH creates many processes, which is a concequence of the toolchest approach.
    1.44 +In earlier times
    1.45 +.Fu fork()
    1.46 +had been an expensive system call, as the process's whole image needed
    1.47 +to be duplicated. One common case is replacing the image with
    1.48 +.Fu exec()
    1.49 +right after having forked the child process.
    1.50 +To speed up this case, the
    1.51 +.Fu vfork()
    1.52 +system call was invented at Berkeley. It completely omits copying the
    1.53 +image. If the image gets replaced right afterwards then unnecessary
    1.54 +work is omited. On old systems this results in large speed ups.
    1.55 +MH uses
    1.56 +.Fu vfork()
    1.57 +whenever possible.
    1.58 +.P
    1.59 +Memory management units that support copy-on-write semantics make
    1.60 +.Fu fork()
    1.61 +almost as fast as
    1.62 +.Fu vfork()
    1.63 +in the cases when they can be exchanged.
    1.64 +With
    1.65 +.Fu vfork()
    1.66 +being more errorprone and hardly faster, it's preferable to simply
    1.67 +use
    1.68 +.Fu fork()
    1.69 +instead.
    1.70 +.P
    1.71 +Related to the costs of
    1.72 +.Fu fork()
    1.73 +is the probability of its success.
    1.74 +Today on modern systems, the system call will succeed almost always.
    1.75 +In the 80s on heavy loaded systems, as they were common at
    1.76 +universities, this had been different. Thus, many of the
    1.77 +.Fu fork()
    1.78 +calls were wrapped into loops to retry to fork several times in
    1.79 +short intervals, in case of previous failure.
    1.80 +In mmh, the program aborts at once if the fork failed.
    1.81 +The user can reexecute the command then. This is expected to be a
    1.82 +very rare case on modern systems, especially personal ones, which are
    1.83 +common today.
    1.84 +
    1.85  
    1.86  .H1 "Draft and Trash Folders
    1.87  .U2 "Draft Folder