[ could you please not send mail wider than 75-or-so columns to these
  lists?  It maks reading and replying ... a fair bit harder/uglier. ]

>As you seem to have guessed, this was in `The Design and Implementation of the 4.4BSD
>Operating System' on page 80: It goes:
>
>     The layout of the process state was completely reorganised in 4.4BSD. The goal
>     was to support multiple {\em threads} that share an address space and other
>     resources. Threads have also been called {\em lightweight processes} in other
>     systems.
>     ...
>     The reorganisation of the process state in 4.4BSD was designed to support threads
>     that can select the set of resources to be shared, known as {\em variable
>     lightweight processes [Ref]. Unlike some other implementations, the BSD model
>     associates a process ID with each thread, rather than with a collection of threads
>     sharing an address space.
>     ...
>     The process structure (with diagram) was shrunk to 1/4 of its former size [in
>     4.4BSD]. The idea is to minimise the amount of storage that must be allocated to
>     support a thread. The 4.4BSD distribution did not have kernel-thread support
>     enabled, primarily because the C library had not been rewritten to be able to
>     handle multiple threads.
> 
>Does the ``not enabled'' bit mean that it isn't in fact there?

For complete correctness, the last sentence should have been, "The
4.4BSD distribution did not have kernel-thread support."  (That is,
just kill everything after the comma.)

Indeed, the process structure was shrunk, and many parts were made
refcounted and shareable.  However, kernel support was not added to
4.4BSD (or Lite, or Lite2) for a "fork(), but sharing some stuff"
system call.  (Some BSD systems have since implemented an rfork() call
which does this.)

It is also true that the C library needed to be made reentrant to
support threads in this way, but that would not have prevented
an rfork() system call from existing in the kernel, and from working
for those applications which were careful about its use.

Much of the support work was done (e.g. splitting the proc structure
and making chunks shareable), but the actual implementation of threads
(via rfork()) was simply not done, and the book is incorrect if
claiming that it was.  There's not an "enabled vs. disabled" issue,
because there is no rfork()-like code in the 4.4BSD (or Lite, or
Lite2) kernel to be enabled or disabled.  It's just not there.


Later, somebody (I forget who) said that it might have been in 4.4,
but not in Lite:

"no."  that is simply not the case.



> What else do you think
>they are rabbiting on about?

Well, recent comments on the mailing lists have led me to believe that
there might also be some inaccuracies about kernel stack red-zoning.
Apparently, the book claims that at least some ports use or used
red-zones around the kernel stack to prevent overflow into the _user
are_ (i.e. invalid pages between the user area and the stack).  I'm
aware of no ports that did that, though some that put invalid pages
"on the other side" of the user area, allowing corruption of the user
area but nothing else.  However, i've not actually had time to look
further into that, and the quote from the book that was sent to me
wasn't large enough to know exactly what was being claimed.


There are undoubtedly more, similar instances.  None of them
particularly detract from the description of the design of the code
(because what's being described is what the 'right' design would look
like when completely implemented, where 'right' is defined by the
authors of the book 8-), but it does make the book ... less useful as
a reference which describes the actual system.



chris