Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!decwrl!labrea!glacier!jbn
From: jbn@glacier.STANFORD.EDU (John B. Nagle)
Newsgroups: comp.unix.wizards
Subject: Re: light weight processes and threads
Message-ID: <17129@glacier.STANFORD.EDU>
Date: Tue, 14-Jul-87 01:56:22 EDT
Article-I.D.: glacier.17129
Posted: Tue Jul 14 01:56:22 1987
Date-Received: Wed, 15-Jul-87 04:21:02 EDT
References: <8272@brl-adm.ARPA> <3872@spool.WISC.EDU>
Reply-To: jbn@glacier.UUCP (John B. Nagle)
Organization: Stanford University
Lines: 31


      This is an old issue, although it's new to the UNIX world.  Another
terminology one sees is that of "weak fork" and "strong fork".  The
UNIX fork is a "strong fork"; the new process gets its own data space 
and operating system context.  A "weak fork" operation has been provided
in many operating systems as an aid to programs that require internal
multiprogramming.  A weak fork operation creates a process which shares
data space with the old process (although it probably needs a new stack).
One then has two processes operating on the same data.  Languages such
as Modula II, Ada, Mesa, and Cedar, which support a shared-memory model
of multiprogramming, can usefully use such an operating system primitive
(and usually have to fake it in painful ways when it isn't present.)

      Generally one thinks of weak and strong fork operations as being
available to user programs.  But the operating system needs processes
too.  The UNIX kernel originally had no processes of its own, but over
time, some have been hacked in (and "hacked" is definitely the right
word here).  With the ever-increasing demands made on the kernel
(particularly networking and windowing support) the desire for the kernel
to assume a more active role rather than being merely a protected subroutine
library increases.  Thus, means of efficiently giving the kernel some
processes of its own so it can further its own goals instead of just
servicing user requests are being invented.  "Lightweight processes"
are one of these; Richie's implementation of "streams" are another
way of cleaning up the kernel's internal multiprogramming.

      Personally, I'd like to see faster context switching, faster
gatekeeping, more process switches, and smaller kernels.  But since the
triumph of vanilla hardware, this is a faint hope.

					John Nagle