Mercurial > docs > master

comparison ch03.roff @ 21:bb8a8be49024

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Wrote about Face support and vfork().
author markus schnalke <meillo@marmaro.de>
date Mon, 07 May 2012 15:50:09 +0200
parents 7a100c80fa91
children 99409e4546d2
comparison
equal deleted inserted replaced
20:7a100c80fa91 21:bb8a8be49024
106 .U2 "Removed support for header fields 106 .U2 "Removed support for header fields
107 .P 107 .P
108 The `Encrypted' header had been introduced by RFC\^822, but already 108 The `Encrypted' header had been introduced by RFC\^822, but already
109 marked legacy in RFC 2822. It was superseded by FIXME. 109 marked legacy in RFC 2822. It was superseded by FIXME.
110 Mmh does no more support this header. 110 Mmh does no more support this header.
111 .P
112 Native support for `Face' headers
113 had been removed, as well.
114 The feature is similar to the `X-Face' header in its intent,
115 but takes a different approach to store the image.
116 Instead of encoding the image data directly into the header,
117 the the header contains the hostname and UDP port where the image
118 date could be retrieved.
119 Neither `X-Face' nor the here described `Face' system
120 \**
121 .FS
122 There is also a newer but different system, invented 2005,
123 using `Face' headers.
124 It is the successor of `X-Face' providing colored PNG images.
125 .FE
126 became well used in the large scale.
127 It's still possible to use a Face systems,
128 although mmh does not provide support for any of the different systems
129 anymore. It's fairly easy to write a small shell script to
130 extract the embedded or fetch the external Face data and display the image.
131 Own Face headers can be added into the draft template files.
111 .P 132 .P
112 `Content-MD5' headers were introduced by RFC\^1864. They provide only 133 `Content-MD5' headers were introduced by RFC\^1864. They provide only
113 a verification of data corruption during the transfer. By no means can 134 a verification of data corruption during the transfer. By no means can
114 they ensure verbatim end-to-end delivery of the contents. This is clearly 135 they ensure verbatim end-to-end delivery of the contents. This is clearly
115 stated in the RFC. The proper approach to provide verificationability 136 stated in the RFC. The proper approach to provide verificationability
141 still offered the switches 162 still offered the switches
142 .Sn \-erase \fUchr\fP 163 .Sn \-erase \fUchr\fP
143 and 164 and
144 .Sn \-kill \fUchr\fP 165 .Sn \-kill \fUchr\fP
145 to name the characters for command line editing. 166 to name the characters for command line editing.
146 The times when this had been neccessary are long time gone. 167 The times when this had been necessary are long time gone.
147 Today these things work out-of-the-box, and if not, are configured 168 Today these things work out-of-the-box, and if not, are configured
148 with the standard tool 169 with the standard tool
149 .Pn stty . 170 .Pn stty .
171
172 .U2 "Vfork and Retry Loops
173 .P
174 MH creates many processes, which is a concequence of the toolchest approach.
175 In earlier times
176 .Fu fork()
177 had been an expensive system call, as the process's whole image needed
178 to be duplicated. One common case is replacing the image with
179 .Fu exec()
180 right after having forked the child process.
181 To speed up this case, the
182 .Fu vfork()
183 system call was invented at Berkeley. It completely omits copying the
184 image. If the image gets replaced right afterwards then unnecessary
185 work is omited. On old systems this results in large speed ups.
186 MH uses
187 .Fu vfork()
188 whenever possible.
189 .P
190 Memory management units that support copy-on-write semantics make
191 .Fu fork()
192 almost as fast as
193 .Fu vfork()
194 in the cases when they can be exchanged.
195 With
196 .Fu vfork()
197 being more errorprone and hardly faster, it's preferable to simply
198 use
199 .Fu fork()
200 instead.
201 .P
202 Related to the costs of
203 .Fu fork()
204 is the probability of its success.
205 Today on modern systems, the system call will succeed almost always.
206 In the 80s on heavy loaded systems, as they were common at
207 universities, this had been different. Thus, many of the
208 .Fu fork()
209 calls were wrapped into loops to retry to fork several times in
210 short intervals, in case of previous failure.
211 In mmh, the program aborts at once if the fork failed.
212 The user can reexecute the command then. This is expected to be a
213 very rare case on modern systems, especially personal ones, which are
214 common today.
150 215
151 216
152 .H1 "Draft and Trash Folders 217 .H1 "Draft and Trash Folders
153 .U2 "Draft Folder 218 .U2 "Draft Folder
154 .P 219 .P