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