Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Message-ID: <31910@bu-cs.BU.EDU>
Date: 28 May 89 14:02:41 GMT
References: <106326@sun.Eng.Sun.COM> <31756@bu-cs.BU.EDU> <8565@chinet.chi.il.us>
Organization: Boston U. Comp. Sci.
Lines: 59
In-reply-to: les@chinet.chi.il.us's message of 27 May 89 04:21:25 GMT


n creating a process context by sharing>Can someone explain how a thread differs from a fork, and whether the
>difference is desirable compared to forks with shared text, copy-on-write
>data, and the ability to explicitly request shared memory for data?
>
>Les Mikesell

Unfortunately a "thread" is not yet a well-defined word. All it seems
to mean at this point is a light-weight process context tho some
implementations exist for guidance of a discussion.

By and large a process has several data structures associated uniquely
with its state; memory, open files, signals, ownership, resource
limits, stack state etc. A thread or light-weight process attempts to
speed up and lighten creation and other overhead by sharing some or
all of these resources with the creating process (the parent or task
in Mach.) Instead of copying resources (or creating them anew in some
cases) they are just referenced, the thread points back at the
parent's data structures. This can be done fairly quickly as compared
to copying and references are lighter to lug around than entire
structures.

Copy on write is just a lazy evaluation technique (albeit very clever
since many processes ultimately need to copy very little of the memory
context, particularly in the typical fork/exec paradigm.) You wait
until it's needed instead of doing the copying in advance in the hope
that little will really need to be copied (of course, the cost at that
point is a little higher since noticing the process needs a copy later
generally requires managing a page fault.)

Shared text is a thread-like notion, but only one part of the picture.

Explicitly shared memory is similar although making the implementation
as efficient as you can when the process says in advance "I'm sharing
everything!" is probably impossible. In the first place it still
implies the sub-process has its own page tables as some things are
shared and some things are not (on some systems it is possible to
share everything in one shot and have the O/S notice that, again,
thread-like, but there's more.)

Something worth considering if you're still confused is the signal
context. In a thread you're guaranteed that all signal handling set-up
will be shared. Changing the signal handler for one thread changes it
for all the threads. There's no way, for example, to have only one
thread responsible for handling SIGINTR, they'll all see it (tho all
but one can deduce they are not the one to handle this signal and go
back to what they were doing, but that's application code not O/S code
as it is/can be with processes.)

Some consider that a bug, some a feature.

See Aral, Gertner and Langerman's article in the past (San Diego)
USENIX on this topic. Also Mach and Sun's documentation. There are
other good references.
-- 
	-Barry Shein

Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202